I think of trying to add drumgizmo as an engine.
It can be compiled as LV2-Plugin.
Would it be easier to use the plugin within jalv ?
Aaaaand, to be honest, It would save some effort for me,
if you could point me to a good starting point in the source.
Examples for jalv plugins maybe. Didnt find them at first sight.
I have seen a posting by Jofemodo, but cant find it anymore…
… I would appreciate any hints on where the logs are.
I see the UI-log in the webconf.
Do we have a syslog?
Midi logging doesn’t show anything (I have a small alesi vmini on USB)…
LV2 plugins have two interfaces they need to deal with. The graphical interface and the LV2 automation interface. I’ve seen a few times where a developer has enabled a control in the graphical interface but then hasn’t exposed it in the LV2 automation interface. Some might not make sense, like a filepicker, sometimes they just don’t get around to it.
I looked into the ttl file, there is really only one input defined, which is the wheel…
The tutorials for drumgizmo (with ardour) always show a gui part for picking the drumset and the channel setup. I don’t see that on the zynthian.
So the process might have exited, crashed or whatever. In the source there seems to be no way to provide the information obtained with the gui through the ttl.
It wouldn’t fit into the concept /design anyways.
Do we have means to simulate the input (or even let the application run its own windows) ?
If not there’s still the possibility of running drumgizmo as native engine in old school command line mode.
Would require a python module for that though.
I’m not sure if I have the time for that.
The Avlinux drumkits are quite good after all.
And Drumgizmo in max mode eats ram like nothing, it’s not sure we get good results in restricted environment. Maybe only on a pi4 / 4gb.
I think we should ALWAYS implement via the GUI as a required characteristic of the mechansim. Running the gui on a touchscreen is pretty hideous from what I’ve seen. ssh -Y ( putty with x10 forwarding) is probably going to be the preferred way of driving an interface, and that’s really something that makes many assumptions of both the system and the operator.
For a minimum use case we should be able to throw any or all parameters up on a screen with sensible driving characteristics. . .
The developer says no way to go around the gui call with the lv2.
No lv2 then, will try with an engine.
For that I have a question :
Drumgizmo ist outputting every instrument on a different Chanel per default, so you could mix the drumset. Zynthian seems to assign only one per engine. It would be a bad idea to start 16 instances, definitely not enough ram/cpu in a raspi for that.
Do you have an idea how to do the 16 channels at once?
There are several engines using more than 1 MIDI Channel: setbfree, aeolus
Also, mod-ui engines doesn’t have a MIDI Channel assigned and receive all off them.
Thanks for the help.!
…but I’m leaving it for a while, will proceed to buliding the drum pads.
Zynthian can do with the quite good drumsets as sf2. Drumgizmo is difficult to integrate and constantly throwing xruns, if not crashing.
I fear it won’t work satisfactorily on a pi3.
I think you choosed a quite difficult-to-integrate engine, my friend.
Normally, i don’t try to integrate any engine that depends heavily on a complex GUI.
Well, yes.
I’m not afraid of complex solutions, that was what I liked when I was
still at work. Just recently I had retired and since then I’m doing childcare
He’s a wonderfull son, but still, I had something else in mind…
… I don’t think it is impossible on a pi4.
Drumgizmo has a cli, one can gather the parameters on the zynthian and start as an engine. In this project you are all very nice and helpful, you pointed me allready in the right direction.
But it’s more work. Maybe when the wave is over and my son can go to school I will have more time.
Till then I will work on the drumpads and the amp/speaker system.