It uses JUCE 7, which now supports LV2. I didn’t try to build to ARM yet but I could give it a go if some people are interested here. And contributors are very welcome too
Of course, I’m really interested in testing your plugin in zynthian, and adding it to the official collection if it works nicely. Please, try to build it for arm.
Hmm damn, their raspbian buster image doesn’t seem well-supported anymore:
E: Repository 'http://archive.raspberrypi.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'oldstable'
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
Error: Process completed with exit code 100.
I’m not sure how this would integrate with Zynthian. The multitrack feature seems to require that the plugin feeds multiple MIDI channels but Zynthian assigns one MIDI channel for each chain. MIDI Clone doesn’t help because it changes the MIDI channel of notes. Maybe a chain with this plugin in it could be routed (via chain options MIDI output menu) to other chains. I’m moving between properties this weekend so my Zynthian is packed away. It will be fun to try this out next week. Maybe a different / better integration method may become evident.
@riban How does ZynthianOS handle plugin isolation? The multitrack feature can also be achieved by having several instances of the plugin set to communicate (Multi-instance mode in the doc), in which can you can have one instance per channel. They just share a singleton object pointer and some lock to do so. I didn’t test the LV2 version of the plugin with that feature yet, though (I’m using Bitwig as my main DAW, and even if it supports Linux really well, sadly it doesn’t support LV2).
Interesting and cool! Zynthian filters and processes MIDI before despatching to the relevant chain(s), i.e. a chain assigned MIDI channel 3 only receives MIDI messages on channel 3 but (most) CC are filtered and despatched to the chain on which it is learned.
@YPares you say this ia a GUI-less plugin but the makefile still depends on freetype but can’t find it. Can you fix the makefile, e.g. remove the UI dependancy or add /usr/include/freetype2 to Header Search Paths in the settings section of ProJucer? I don’t know why/how to fix JUCE_CXXFLAGS other than manual makefile change - maybe you can look at that in ProJucer too.
No it does have a GUI, but it just amounts to listing/setting the parameters it exports (therefore it’s usable without that GUI if you have a display like Zynthian’s which already allows to see and set the parameters).
I got past the freetype2 dependancy by bodging the makefile but there are a lot of gui dependancies. It would be best to disable gui dependancy completely or to export the deps to the makefile. It looks like some config is wrong because the makefile expects the gui libs but does not define where to find them.
[Edit] Got further by disabling JUCE_MODULE_AVAILABLE_juce_graphics, JUCE_MODULE_AVAILABLE_juce_gui_basics & JUCE_MODULE_AVAILABLE_juce_gui_extra. Maybe these are options in ProJucer. (I don’t use it so don’t know.)
[Edit] It looks like the dependancy on webkit2gtk-4.0 is still breaking it. Does it have a web interface?
No, webkit2gtk is not necessary sorry (So far I had left JUCE GUI options as default, Arpligner is my first JUCE project). I’ve made a fewer-gui-deps branch where I reduced the number of deps Reduced number of GUI deps on Linux by YPares · Pull Request #11 · YPares/arpligner · GitHub. But I didn’t manage to fully remove the GUI as removing the juce GUI libs you mentioned above also removes some classes I depend on for dealing with parameters, but that should be unrelated. Will try to investigate further.
I first run the command detailed here but that uninstalled jack2 in favour of jack1 which would have broken everything so I uninstalled that stuff and reinstalled the stuff that was there before - I might have not listed all the dependant packages.
but no controls exposed to LV2 host via manifest / ttl. I haven’t figured out how it works so it is not doing much for me yet. I have managed to get MIDI to pass when bypassed plugin in the GUI and got some processed MIDI when set to [Multi-instance] Pattern instance so it is doing something. I have to do other stuff now but may find time later to read the instructions… and maybe even tweak the ttl file - but no promises!
[Edit] I uninstalled libwebkit2gtk-4.0-dev and it compiles okay - lots of warnings but that might be related to the version of compiler / libraries or tardiness on the part of the JUCE developers.
Add a synth chain on MIDI channel 2 and inserted Arplinger into that chain
Set Instance behaviour to [Multi-chan] Chords on chan 1
Set When not chord note to Silence (to avoid continual playing of chord)
Create an arpeggiator pattern in zynseq on channel 2
Add a MIDI chain with MIDI thru on MIDI channel 1
Routed MIDI from chain 1 to chain 2 (this might not be an option in stable / testing - it may have been added in my dev branch)
Playing chords on MIDI channel 1 will result in the sequence arpeggiating the chord
At least I got something out of it. There needs to be a way to configure the plugin without accessing the native GUI, i.e. the controls should be exposed as LV2 control ports. Maybe the default (preset maybe) sets the parameters to ones that work for Zynthian. I haven’t yet got Multi-instance working but now I understand how to get some sound out I will have a bash…
[Edit] Multi-instance is sending lots of zero velocity note-off commands but no note-on commands. I can’t get this to work.
Hey! Thank you for your efforts !
Okay, the parameters not being exposed to the host in the LV2 case is definitely a JUCE limitation/bug. (TTL/Manifest generation is fully up to JUCE, I may have some control over it in the Projucer but not over that). LV2 support is fresh in JUCE (got released only 3 months ago I believe), but I don’t recall seeing that limitation listed (what would be the point anyway to support LV2 without that?), so I’ll open some issue(s).
Multi-instance is sending lots of zero velocity note-off commands but no note-on commands. I can’t get this to work.
Okay, I see where that could come from (but it’s weird it’s only in multi-instance). I’ll try to fix. Thx for opening the issue!
Yep! Multi-instance isn’t working as expected. I will leave that to you to investigate.
JALV only seems to allow control of control ports, not parameters via its CLI. JUCE presents controls as parameters. In JALV you see the names and (apparent) values of the parameters but attempts to set these fail. Direct numeric access controls the ports which are not displayed in jalv’s controls command. I think this is a flaw / limitation of jalv but means we can’t currently host JUCE LV2 plugins in Zynthian.
Is this another nail in JALV’s coffin and a reason to write that new LV2 host?
I guess multi-instance depends on each instance being instantiated by a single process. Maybe a different LV2 host would allow this. I will check in mod-ui.
I’m developing GitHub - YPares/arpligner: A multi-track & polyphonic arpeggiator plugin that takes both chords and arp patterns as live MIDI data. It’s usable in a totally GUI-less fashion (there are just a few exported controls), so it could be quite suited to a platform like the Zynthian. It’s built around the spirit of enabling you to reuse any MIDI sequencing gear/software you already own (be it a piano roll, an instrument, a hardware seq, etc) instead of having you stick to a rigid 16-step-like grid.