Usage of Midi Tools LV2 Plugins


#1

In the web interface, JALV Plugins selection page: do the "Midi Tool"s that can be selected there show up in any of the layer lists? I cannot find them in the “NEW Synth Layer”, “NEW Effect Layer” or “NEW Generator Layer”. Am I missing something?


#2

I will answer this question myself: enabling the MIDI plugins was easy with this patch:

zynthian_gui_layer.py.patch (1.2 KB)

But using the plugins requires them to be routed in the midi path. So here comes the next question (maybe to @jofemodo?): Would you rather develop a midi routing like the audio routing is done or by modifying the ZynMidiRouter?

By the first I mean that every engine gets a “midi_in” property analogous to the “audio_out” this could then be edited in the Layer Options.

By the later I mean that the ZynMidiRouter gets optional ch{}_in inputs that can be connected to a MIDI plugin output and, if present, is routed to the corresponding ch{}_out instead of to the filtered main_in.


#3

Thanks @jgeisler0303!

Of course, i would like to improve the MIDI routing in the way you say, and i will do. It’s just a question of time …

Zynthian-UI is improving quite fast in the last months/weeks. Jalv engine is available only from about 2 months ago. And FX chain is a very recent development, released 2-3 weeks ago :wink:

I see you have a lot of fresh energy and that’s wonderful! I really appreciate it and would like you could contribute as much as you want to the project. That’s the spirit! :wink:

Anyway, please, i also would appreciate you to use the tools we use for developing, as it’s a lot easier for coordinating the tasks, having traceability, testing, merging changes and of course, attributing the merit of every fix or improvement.

We use git as versioning tool and github as git server and issue/task tracker. If you are a punctual contributor, you should follow this procedure:

  • fork the repository
  • make the changes
  • test it
  • make a pull request

When you are a habitual contributor, you will receive write access to the repositories you master and would use “development branches” instead of “forking/pull-requesting”.

Also, it’s a good habit to create a task/issue associated with more relevant changes, specially if you are a newcomer. In such a way other developpers will be informed of your intention of implementing a new feature or fixing a bug and will avoid overlapping efforts, at same time allowing other developper to contribute to your task by adding useful knowledge and alternative approaches.

Kind Regards,


#4

Oh, of course I will follow the work flow (just forked the repo). I just wanted to get some direction before I write too much code that go in the wrong direction. I will move my questions and hopefully a lively discussion to the github issues.