So I have to load SLB files to get my sooperlooper setup going in the meantime… I’ve tried to add -m to zynthian-engine-sooperlooper.py (around line 326 where it starts it up sl), was actually surprised to see that didn’t let me load the slb like that, loading it via slgui works though, any idea what might be going on here?
You put your slb in this location:
/zynthian/config/sooperlooper/zynthian.slb
And It will be loaded by sooperlooper on startup.This only works in testing.
Regards
thank you very much, that’s fantastic, trying it now
set the file up., rebooted, removed sooperlooper added it back in, but the midi mappings in the slb didn’t load
oh yeah, I’m on vangelis, is that ok?
I’ve pushed some fixes and improvements, including the automatic run of slgui when VNC is enabled.
Please update and try again.
Regards,
Awesome giving it a go now
Ok so here’s what I saw… The slb loaded just fine now
There is some bad news though I think the zynthian gui no longer receives updates from sooperlooper, it did appear to receive instructions from it though
slgui also closed after a preset change, dont know if thats important or not
I would take a look tomorrow.
Regards,
Ok interesting, after another go at it, zynthian did connect to sl now… so might not be worth digging for a fix for it
Alright, did a thorough test, there’s nothing wrong with the setup, the slgui is staying open when changing preset too, everythings fine, no clue what was up with it last night.
Thanks for the update it’s working very well, I’ve got most of a working loop setup in place now, offhand effects by mapping some global cc’s, the ability to play instruments, and the ability to record a few channels of loop
Alright, so I do have some further feedback… I managed to recreate the error where the zynthian gui doens’t receive updates from sooperlooper again, not sure why it stopped happening, cause it’s happening fairly consistently now… closing slgui with ‘close but leave engines running’ didn’t have any effect.
I did see a log in the error logs for the ui (happens over and over again, but only when on the gui screen)
Nov 26 11:44:23 zynthian startx[942]: WARNING:zynthian_widget_sooperlooper.refresh_gui: ‘waiting’
This error probably doesn’t really affect me since my mapping is already done and I’m about to add my little alsa program that lights up the midi lights on the apc25, so that I don’t need any screen feedback, but if there’s any tests you’d like me to do I’d be happy to.
SL has per channel and selected channel messages. I wonder whether your binding uses the opposite to what zynthian currently uses?
I’m not 100% certain if its related to the binding… I just removed the sooperlooper cause I ran into a dead end trying to get it to load with all the syncs turned on, so I set up a new one on the last chain, and right now slgui, my mapping and the zynthian gui is loaded
just checked, it survived a reboot too…
weird, I’m kind of scared to mess with it too much, I’ll back up these files and see if I can make the error happen again, I almost feel like its ok as long as sooperlooper is the last chain…
my mapping does use the individual buttons, but updates are happening just fine after deleting sl and adding it back in
thanks @jofemodo the SLB loading gave me exactly what I needed, I’m almost finished writing a device driver for the APC25 that replaces the SLB but I desperately needed the SLB to load to finish testing and building it, almost done!
so a workaround for sooperlooper not picking up is replacing it with another effect and then replacing it back again, It also seems auto starting slgui might be a bit overkill, maybe a way I can prevent slgui to save battery? for now I can switch vnc off I guess
Yikes! We should not be starting slgui automatically. This gui client can be useful for testing some elements and can be started and stopped on demand. Almost everything it can do we can also do in code. It has flaws, like if it loses connection then it does not always reconnect and you can have orphaned instances. I don’t like this change.
slgui is now started automatically if VNC is enabled. Just like the rest of engines.
I did a fast implementation 3 days ago, so perhaps some adjustment is needed.
Regards,
Is it me, or can SLB only be used when:
- the chain where SooperLooper is in is active and of the type audio+midi, and
- the device is set to non-multitimbral?
Sooperlooper is configured as a “single instance engine”, i.e. you can only add it once to a snapshot. This may be the cause of your confusion. It can be added to any audio chain (audio, synth, generator, special). The device does not need to be set to chain mode - indeed, the device is not tied to any chain.
No, I’m talking about the midi CC messages not seeming to be sent to the engine when that engine is either in the master chain or a audio (no midi) chain.