Oh, and I hadnt tried using CCsend as it wasnt enabled on either system, but that’s working too.
1 Like
I didn’t have much chance to play around with the 2 control plugins last night, but it did get me thinking (which is generally never good)
How customisable could these be in terms the number of CCs per instance and would it be possible to use the envelope widget at all?
At it’s most basic would it just be a case of (for example) of recompiling the CCsend plugin with the required number of CC parameters and then editing a custom .ttl with the names and desired groupings including the correct envelope tags (designation?)
I tried adding some envelope designations to the existing CCsend plugin, but didn’t have much success, although I admittedly have no real idea what i’m doing, and generally only sporadically dabble in coding.
I have quite a few small synth modules, with no or minimal display and often require 2 hands to menu dive and select parameters, which is less than optimal, so was wondering how easy it would be to use a Zynthian and controller as a bit of an hub for external devices.
One of the modules is a Korg NTS-1 (mk1) which has no patch memory, but I have already established that I could use ZS3s (or just presets) as a patch librarian as its just a case of recalling and sending cc data to the NTS-1.
What might be even better would be for the plugin to be able to read something like a CSV file (or converted copy) similar to that at midi/KORG/NTS-1.csv at main · pencilresearch/midi · GitHub but I have no idea about LV2 programming and whether something so dynamic is possible in the framework.
I’m (very) slowly, working on integrating Zynthian into my setup having previously really only used it for DEXED, drums and a bit of reverb.
I’m also quite close in getting a workable version of a device-control driver for a Korg Keystage (the code is a mess and pretty buggy, but mostly works, including showing Zynthian info on the Korg display) - Will post some pictures/video when I get a chance.
Hi @SteveFlesh! I am not sure what you want to do. There are a few ideas in your post but the only thing I really get is the concept of using zynthian as a patch recall for external devices which, as you observed, can be done with one of these plugins and zs3.
Hi @riban, yeah there’s quite a few ideas in there.
As you say patch recall already works, so that’s all ok.
Using the CCsend plugin as an example, currently the plugin has 8 ‘slots’ which can be assigned cc’s from the config pages. On the CC#1 group the control knobs are named Ctrl A - D (or something similar) and CC#2 E - H.
Sticking with just 8 slots for the moment, If I wanted to assign 4 of them to CCs which control an ADSR Amp envelope and the other 4 to a ADSR Filter Envelope could I, by editing the ttl or otherwise -
a) rename Ctrl A - D/ E - H to Attack, Decay, Sustain, Release, so that is what is displayed on the Zynthian screen and
b) have the plugin use the Envelope Widget for these groups.
Then also -
c) extend the number of cc slots (to 12 for example) and rename the remaining 4 to something like Cutoff, Res, Delay Mix, Reverb Mix ? These would use the normal non-envelope widget display. (I assume this would require recompiling CCSend to increase the cc count to 12)
I was thinking of using the plugin as a framework for creating specific versions for a few external hardware modules, but with the correct number of parameters and names rather than CTRL A or the CC number for each hardware unit. If I was just creating a few and it was all possible, then I was hoping it would just be a case of editing a ttl or other file. (recompiling if necessary)
The other idea really ‘just’ followed on from that, asking could the number of cc’s, their names, etc could be read by an LV2 plugin (or similar) from another file(e.g csv or xml) to create a version for a particular hardware unit. This is probably too big an ask though.
(btw i’ve not explored Midi Control External plugin much more yet, it looked useful, but may expose too many cc’s to scroll through - apologies if this does already do any of the above)
I guess what I might asking for, is something akin to a very simplified Ctrlr within Zynthian, however I don’t think Zynthian would be the best platform for in depth patch editing, but exposing a dozen or so simple patch editing CC’s and performance CC’s might work.
Does the above make any more sense?
Of course a lot of stuff like this is supposed to be being solved by Midi 2.0, but progress on this is still really slow and still wouldn’t solve the problem for Midi 1.0 devices. (some kind of midi 1.0 to midi 2.0 bridge plugin could get round this, but that would still be a whole lot of work)
Okay, so your core idea is for the plugin to have configurable parameter names and variable quantity of controllers. That’s an interesting idea. Add a feature request to the GitHub page of the plugin.
2 Likes
these could be implemented as presets and saved as yaml files (for instance). Initially, these presets could be generated by hand and later, if enough interest, a UI tool could be developed. 2 steps 
2 Likes
The ttl for ccsend is installed in /usr/lib/lv2/ribanCCSend.lv2.
You can change the display names of the plugin by editing the ttl, e.g.
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 6 ;
lv2:name "Attack" ;
lv2:symbol "send_a" ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
] ,
To display the envelope editor is more complex because this plugin uses integer values for its controls but zynthian code only shows the editor for floats. So some changes would be required to the zynthian or plugin code to facilitate that. A feature request would be required, probably best submitted on the zynthian side.
The ttl changes for envelope would be:
- Add param prefix:
@prefix param: <http://lv2plug.in/ns/ext/parameters#> .
- Add an envelope group
<urn:riban.ccsend#env>
a param:EnvelopeControls ,
pg:InputGroup ;
lv2:name "Envelope" ;
lv2:symbol "env" .
- Add each control to the envelope group:
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 6 ;
lv2:name "Attack" ;
lv2:symbol "send_a" ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
lv2:designation param:attack ;
pg:group <urn:riban.ccsend#env> ;
] ,
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 7 ;
lv2:name "Decay" ;
lv2:symbol "send_b" ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
lv2:designation param:decay ;
pg:group <urn:riban.ccsend#env> ;
] ,
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 8 ;
lv2:name "Sustain" ;
lv2:symbol "send_c" ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
lv2:designation param:sustain ;
pg:group <urn:riban.ccsend#env> ;
] ,
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 9 ;
lv2:name "Release" ;
lv2:symbol "send_d" ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
lv2:designation param:release ;
pg:group <urn:riban.ccsend#env> ;
] ,
BTW @jofemodo MIDI Control External is not loading on my RPi5 build running zynbleton branch.
[EDIT] My bad! I broke it and you fixed it. (I will update to pull the fix.)
1 Like
That’s great info, thankyou.
I had a bit of a play last night, and got pretty close to a custom version by recompiling with 12 ccs and editing the ttl with custom names, similar to what you’ve described above.
The bit about the envelope widget and floats would explain why I couldn’t get that working by just adding designation param (although I hadn’t added an envelope group either)
I may have a go at another custom version later today, just to help me formulate a feature request. I’ve just created a githib account, so will add one later.
I’ve just popped a feature request into github, hopefully it still makes sense.
@riban - I’ve also mentioned in the FR that I’ve been unable to compile a working version of your CCsend plugin with >26 controllers by changing NUM_CC.
I did spot something a little odd in the resulting ttl, but don’t know if that’s the actual cause, but could be a clue, snippet below, for index 32 name is ‘Ctrl [’, but symbol is ‘send_{’
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 31 ;
lv2:name “Ctrl Z” ;
lv2:symbol “send_z” ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
pg:group urn:riban.ccsend29#portGroup_send ;
] ,
[
a lv2:InputPort, lv2:ControlPort ;
lv2:index 32 ;
lv2:name “Ctrl [” ;
lv2:symbol “send_{” ;
lv2:default 0 ;
lv2:minimum 0 ;
lv2:maximum 127 ;
lv2:portProperty lv2:integer ;
pg:group urn:riban.ccsend29#portGroup_send ;
] ,
You should report issues with CCSend in the upstream GitHub repo, not zynthian repo.
If you are compiling a custom version, you may wish to change the source code to create the parameters you require, rather than modifying the ttl later. You could remove the feature to dynamically select the CC numbers, hardcode the quantity of CC and call them what you want. The souce code should be fairly simple to understand.
I have added a preprocessor check that triggers a build error if the quantity of CC is greater than 26. The reason for the problem is that each CC is named with a letter (A…Z) suffix. The name is uppercase and the symbol is lowercase so when this is calculated beyong the 26 letters (in the Latin alphabet), we get invalid characters. This could be fixed by using numeric indicies but that would break existing user’s snapshots and it is not required for the default build (8 controls). So I am not likely to change this.
1 Like
Thanks - will remember that for future, just getting to grips with Github workflows.
I think you vastly overestimate my coding abilities🤣 - but at the very least it could be a good exercise for me to improve that. I’ve stuck with modifying the .ttl for the short term whilst I experiment - I at least roughly understand how that works. It’s a little bit of work, but manageable for a couple of devices.
I can see you’ve decided to change to numeric indices upstream - that’s done the trick for me, thank you!
I’m now experimenting with versions for an Korg NTS-1 (29ccs) and a Dreadbox Telepathy Eurorack module (50+ ccs) Other than a slight bug on my end for the Keystage driver I’m working on which I need to fix, both are working pretty well so far.
So thankyou again for the changes - i’ll see about sharing the Keystage driver and custom SendCC files once i’ve done a bit more testing and got my head around Github.
It would be good to abstract what you are doing so that we could create a preset mechanism to load configurations for different devices, like @jofemodo suggested. I am not sure how widely used the plugin is and how beneficial this might be.