Send Midi CC+PrgCH?

I find both very useful.
Hoping that @Jofemodo will be fixed.
@riban SendCC is just flexible you can give each controller a separate midi channel.
This allows you to edit several synths with Midi CC with one instance.
Midi Control from @Jofemondo is quicker to set up and clearer.
Both make sense depending on what you want to do with them.

OK! It’s fixed!
Now it should work.

Regards,

:smiling_face_with_three_hearts: :smiling_face:

Sorry, it’s not fixed! Wait a little bit …

OK! Now it’s working right!

Enjoy!

Yep! That has fixed it.

@jofemodo’s approach is very logical and with the right detailed knowledge of MIDI you can do what you need. There is no configuration required. There is a direct one-to-one mapping of everything with a hierarchical structure. I like the logic which is where I started but I broke from that for reasons of workflow. (This feels like a role reversal. It is usually @jofemodo who is guiding me away from logical implementation towards workflow driven implementation!)

Observations of MIDI Control plugin:

  • Selecting a preset will always send a bank select followed by the program change unless you have chosen bank=none.
  • Only bank select MSB is sent.
  • To send bank select LSB, navigate to page “CC#32 - CC#35” and use “32 LSB” control.
  • CC controls are always consecutively ordered in groups of 4.
  • You can select a program directly without needing to send intermediary program change messages.
  • You need to navigate to the preset page and scroll through to change a program and may need to navigate to bank page.
  • CC number and common usage names are shown in the controllers label.
  • CC value is shown in the controller’s value field.
  • Some CC controllers have their common use constraints applied, e.g. CC64 is a toggle.
  • Controllers have MIDI binding from the same MIDI CC, i.e. sending CC7 to this chain will drive CC7 which will then send CC7. I am not convinced this is the desired default behaviour but have not given it too much consideration.
  • All CC are sent on a common MIDI channel that is set by chain MIDI channel.
  • CC pages are labelled with their CC number ranges, improving access to the required CC.
  • Can be routed to physical (including network) MIDI ports. Cannot be cascaded to other engines.

Observations of CC Send plugin:

  • “CC Send” is not an optimal name. Should we rename it?
  • There are only 8 CC controls, A-H. By default these send CC1…CC8. (I could increase this up to the full 128 max if required but see point about configuration below.)
  • Initial configuratoin is similar to MIDI Control plugin for first 8 cotrollers only, i.e. no extra configuration needed for this limited set of controls.
  • By default all CC send on a common MIDI channel which is set within the plugin.- Each control may be configured to send any CC on any channel.
  • The configuration is done within the UI with normal controls which have the risk of being inadvertently changed (hence why they are at the end of the list of pages).
  • The more controls that are enabled (at compile time) the longer the list and hence the further away (more scrolling) their corresponding configuration controls.
  • Program change may be sent with or without bank select, either MSB or MSB+LSB.
  • Bank select MSB and LSB may be set and sent individually.
  • You cannot select a program change or bank select directly. You must scroll through all values with each intermediary value being sent. (Scrolling fast may skip some due to zynthian’s encoder acceration algorithm.)
  • The CC number and common name is not shown on the CC send controller. These are labelled A-H.
  • CC number and common name is shown in the value field of the configuration control. This may be small, line-split and/or truncated.
  • All CC are continuous, i.e. send values 0…127. None are configured for toggle mode. I could add a configuration for this which further increases the quantity of configuration pages. (I would be tempted to provide a whole config page per send control which may ease configuration by having directly named config pages, e.g. “Config A”.)
  • There is a (rather lame) native GUI shown on the VNC desktop. (This is not intentional and I will probably remove it as it provides no real benefit.)
  • No default MIDI binding but this can be done manually if required using the normal MIDI learn mechanism.
  • Can be routed to physical (including network) MIDI ports. Can be cascaded to other engines to drive their native (not zynthian MIDI learn) MIDI bindings.

As you can see, there are pros and cons for each implementation, some of which can be mitigated by further enhancements, i.e. stealing ideas from one to add to the other. There are a few behaviours that may be more preferential to some users, e.g. direct selection of program vs scrolling through programs which may dictate which plugin a user prefers. It would be good to have just one plugin to rule them all but that may prove too challenging if conflicting features can’t be consolidated. (And it might hurt the feelings of one of us if we were to chose one over the other… but we won’t cry or harp on about it for too many years!)

I tried to be as fair and unbiased in my assesment of both plugins. Feel free to point out anything I missed.

@jofemodo and I basically had the same itch at the same time and each scratched it in a different way. (It is all @highsiderr’s fault!) This has been a bit of fun and I am quite surprised at how many users are finding this useful. I still think these plugins may benefit from a different type of chain, i.e. one that has no MIDI or audio input. They kind of sit within a more global module scope but I see possible advantages to leaving them in the chain scope, e.g. CC Send can be cascaded to drive native CC binding (although that should not be necessary in the (near) future).

3 Likes

I didn’t know it would escalate :stuck_out_tongue_winking_eye: .

But the result is what counts.

I’ve just tried Midi Control.
It now also does what it’s supposed to .
Tested with Deepmind and Pro-800.

2 Likes

Does it work with Ostirus? I guess not due to it not driving internal synths.

BTW an unexpected benefit from these MIDI controllers is it fixes issue 1184. You can use this to send CC from X-Y pad to an external MIDI device. It’s nice when a bug kinda fixes itself. (Or two people inadvertently fix it.) :smile:

1 Like

I have not tried Ostirus because @jofemodo wrote that it is only for external devices.

CC send works great with SurgeXT and Midi learn over VNC .

Yes, this could be a way to temporarily implement control of soft synths that we haven’t yet fully integrated and have their own MIDI binding. We hope to resolve that in the future.

I might expand my plugin to add more controls (though probably not too many). The only issue is navigating. I think there is an optimal quantity that provides enough control but doesn’t span too many pages.

1 Like

I’m going to start with myself.

I usually use Cutoff, Resonance, Vcf env, Decay, Vol and sometimes Lfo Depth when making music.

For Music making 8 controls are enough for me.

If you want to build sounds you should rather use the VNC on the Zynthian (or the external Synth It self).
It is easy to use via the browser.
It is clear and all parameters are accessible.

CC send and Midi Control for Quick access to selected parameters.

VNC to building Presets.

What do others think?

That sounds sensible. Many hardware controllers have 8 encoders / pots but some have more. It is not uncommon to have 9 which allows control of 8 parameters plus overall volume, or act as a controller for a B3 style instrument that has 9 drawbars. We currently only have 4 encoders so anything above that involves navigation but with pages easily navigated it may be reasonable to have a few more than two pages. I would want to keep the quantity of pages of controls low enough to see them all on one page of the list so maybe I double the quantity to 16. Many more than this and we start to scroll and it may become unwieldy. (I am not mentioning any other similar plugins!!!)

:rofl: sorry…

I spent today testing both plugins.

There is a use for each.

CC Send is configurable and is only on a few pages of the UI.

MIDI Control is universal and I use it when I don’t know which CC exactly I will need.

Output test:

  • USB - working
  • QmidiNet - working
  • rtpMidi - not working. I tested a PC with WIN (rtpMidi), a PC with Linux (rtpmidid), a Raspberry (rtpmidi from McLaren). In the direction to Zynthian, data transfer works. In the direction Zynthian → computer on the network, unfortunately, nothing, in my case.
2 Likes

Did we ever decide which MIDI processor for external controller was better…?

There are some that say
MIDI Control External is the way to go

and others contend that

CC Send is the only true path…

Mind you, you have to load CC_Send first to get it…

Obviously there can be only one…

How might we decide…?

But first the REALLY important question…

Control Surface.?