Okay - yes you are right. Sooperlooper integration with zynthian was designed to use zynthian’s CC mapping mecanism, not sooperlooper’s native SLB. We are considering adding MIDI to the main chain. I am working on that now.
Hi @niels !
- Main bus can’t receive MIDI, so you can’t use the SLB mappings when SL is in the main bus.
- For using in any other chain, you must create a MIDI+Audio chain instead of a normal audio chain.
Regards
Awesome, glad it wasn’t me, and have it cleared up for prosperity.
I would also advocate against starting slgui automatically, its so easy to start and if you know what it is you’ll know how to start it
1 Like
@niels that is pretty much exactly how I set it up, device on multi, and audio+midi being the chain (@jofemodo please keep these hahaha)
I’m nearly done replacing slb mappings with my own control surface driver, just wanted to get the lights and preset loading to work first while I test it, now that that’s all working I’ll just port over the button presses to those same commands in the driver
It stands to reason that when there are several quality device drivers out there to copy from, and the code is a little more abstracted and easy to read, that SLB’s will no longer have a purpose at that point
a big issue with this is that many of the more useful and cheap midi controllers for loops do send notes for their trigger buttons
device drivers are an elegant solution, but after writing one I realised its above 99% of peoples paygrade, so some functionality to make device driver creation easier will probably emerge over time
It’s only started when VNC is enabled. And you shouldn’t have VNC enabled unless you are going to use it …
Device drivers are in its infancy! For sure there is a lot of room for improvement.
@jofemodo Sooperlooper integration with zynthian is done with consideration of the supported and appropriate workflows. This means that not all sooperlooper functionality is supported. It is very easy to get slgui and zynthian out of sync, to drive sooperlooper in ways that zynthian does not support. slgui is a useful diagnostic tool but it does not offer extra functionality that is suported by zynthian integration, i.e. any extra functionality will break zynthian integration.
For example, there are many ways to register for notiications including by selected loop and by absolute loop. Zynthian uses some but not all of these to reduce the amount of processing that must be done. This was carefully (and not naively) implemented so that the supported integration works.
Also, you have implemented slgui as the host for sooperlooper. Stopping slgui does not stop sooperlooper so we end up with an orphaned instance of sooperlooper.
I strongly recommend not starting slgui. The user can start it manually if the want it but most users should never need this. We should only present native GUI if it adds benefit. This does the opposite!
2 Likes
OK! I will revert the change and leave users to launch by hand slgui when they needed.
Regards,
1 Like
Done!
Thank you man that helps me so I don’t have to switch vnc off so often
You should have VNC disabled by default. It’s not good for performance. You should only enable VNC when you really need it.
Regards,
1 Like
Yes I do keep it disabled pretty much the whole time apart from when I’m patching, having a more performant vnc helps for when I’m testing presets to keep it open a bit more often