The default mapping only seems to work for master channel and this isn’t perfect so it is easier to just map controls yourself.
There has been a bit of talk in other threads about toggling signals for sooperlooper but this is not required. Sooperlooper does not really have a stop state so you just need to tell it what state to change to. You can assign pedals that fire MIDI CC with value > 0 for each state, e.g.
CC 102: record
CC 103: overdub
CC 104: replace
CC 105: trigger
CC 106: mute
CC 107: pause
CC 108 (value 0): undo
Then you can start a recording by sending CC 102 and end the recording and start loop playback by sending CC 105. To overdub the current loop send CC 103 and to replace the current loop send CC 104. Send CC 105 to resume playback at any time. Sending CC 106 will continue to play the loop but silence output whilst sending CC 107 will pause playback (the closest thing to stop in sooperlooper).
Is it working for you @wyleu ?
I’ve put Master Midi channel to 16 into interface/midi options and a SooperLooper into Main and… no response to my midi CCs.
In the same time @riban at the bottom of the page I see the master key actions list and… 102 is Zynswitch12
#define LED_ON_PAUSE 200 // Length of on LED Display on LEADING edge trigger.
#define MODE_ON_PRESS_OFF 0 // Initially OFF, LED OFF. Sends MIDI ON, LED ON on press, Sends MIDI OFF, LED OFF on release
#define MODE_OFF_PRESS_ON 1 // Initially ON, LED ON. Sends MIDI OFF, LED OFF on press, Sends MIDI ON, LED ON on release
#define MODE_ON_PRESS 2 // Initially OFF, LED OFF. Sends MIDI ON, LED ON on press. No action on release
#define MODE_OFF_PRESS 3 // Initially ON, LED ON, Send MIDI OFF, LED OFF on Press. No action on release
#define TOGGLE_ON 4 // Initially OFF, LED OFF, Send MIDI ON, LED ON on Press Toggle Send MIDI ON, LED ON and Send MIDI OFF, LED OFF
#define TOGGLE_OFF 5 // Initially ON, LED ON, Send MIDI ON, LED ON on Press Toggle Send MIDI OFF, LED OFF and Send MIDI ON, LED ON
Just trying to figure out the best way of doing all that, In a sustainable fashion
I need some way of changing mode on the box, an encoder maybe.? Perhaps it’s a grip of death . . . ?
Has to be at least two devices to provide that. Perhaps have highest and lowest as the accepted response? I now have a second available LED so I can indicate when in admin mode. . .
Should we cast the other thread adrift. . . .tack it unceremoniously on here? or shed this thread in favour of the others. . . We must be down to hardened zynslaves by now…
Hi there !
I’ve read again this topic and understood that i’ve misunderstood a thing…
I was looking at Zynthian UI User Guide - V1/V4 - ZynthianWiki and Interface->MIDI-options->Master Key Actions
BUT, you are talking about CCs and not Notes… Where do your list come from ??
Zynthian allows any control to be mapped to a MIDI CC control via it’s MIDI learning mechanism. You can assign whatever CC you want to whatever control you want.
Is the CC mapping bidirectional, f.e. a motorfader is mapped to a parameter, will it change its position sending values from the Zynthian?
Another question: Loading a preset, will Zynthian send initially sens out the cc values ?
then used Zynthian MIDI learn to map the foot pedals to looper functions which worked well.
Mmmm so that’s also why I can’t find how to midi learn the buttons from Zynthian screen.
I guess you did it via VNC Then the configuration is saved into SL, so it’s “hard routed” and the new way of using the midi devices won’t work ?
We don’t control Sooperlooper with MIDI. Zynthian makes an OSC connection to Sooperlooper and registers for tallies (feedback). In this way the Zynthian UI is updated with the state of the Sooperlooper instance to which it is connected.
The question that @Klangschmied asks is whether Zynthian sends tallies (feedback) for its control values (which are mimics of Sooperlooper’s parameters). The wiki mentions this feature but it is vague. I have never used the feedback feature in Zynthian and from what I have read it is not fully implemented / working or is in a state of flux. I know that @jofemodo , @wyleu and others have MIDI controllers with motorised faders so maybe one of those could give some guidance (and update the wiki).
Would a move to an entirely OSC based control infrastructure with Physical and virtual MIDI only occurring at the periphery be of long term benefit? I perversely, run zynthians headless and crave visual feedback of the actual state of the device. A number of RGB LED’s at the moment.
I build devices to toggle controls but have great need of actual zynth state not the misguided collection of messages I might or might not have sent.
We interface with the engines via whatever mechanism they offer, e.g. Sooperlooper & zynaddsubfx offer OSC interfaces whereas other devices may use MIDI or CLI for control and monitoring. We will continue to abstract each engine to a common zyngine object.
I think what you may be hankering after is an API that is presented in a consistent hardware layer interface, e.g. OSC. We have discussed this at length and are getting close to this every day. CUIA is currently implemented and accessible via OSC but it is not a full API. We will get there…
This topic discusses SooperLooper and some users are trying to interface directly with the instance of SL running on Zynthian, bypassing the Zynthian API / CUIA. Ideally this would not be necessary, with Zynthian exposing all required parts of the engine but it would appear we are not there yet. What is probably quite important is to avoid driving elements of the engine that would subsequently leave Zynthian out of sync. I think / hope that the SL implementation avoids this because the controls are also monitored but SL allows different layes of control and it is possible that direct OSC access via one method may not report back to Zynthian which could result in SL being configured in a way that is not represented and/or not controllable by the Zynthian GUI.
Sooper looper seems a perfect target implementation for consideration. There are many ways of configuring this, but, perhaps, we realy want the various flavours of sooperlooper instantiation to be zynthian snapshots that are easily chosen. I’ve not managed to get a reliable rig built in this environment that I would dare to use live, and I’ve seen it used to good effect.
The definition of the API is gaining verbs at a rate of knots which is perhaps a good thing.
We have PLAY and RECORD existing already and there is already an informal development around these . PLAY will run the sequencer but you need to CUIA MIDI Learn to get the Audioplayer to play off a PLAY event.
… Is it a good moment to talk again about a Zynthian - OSC - bridge ?
Yes I’m not a developer, and yes it’s just an idea that look simple to me but can be as simple to make or… Absolutely not.
We can do “anything” via osc messages. We may talk to engines thru it, as each engine should have it own osc port. We can then midi-learn devices to osc messages into Zynthian UI that will pass them thru it own midi router then to the engine and then take care of the feedback ?
that said… Zynthian OSC doesn’t care about midi notes and cc into osc messages yet ? Or is it documented somewhere?-
oke, after some searching this is what I want .I 've got a Behringer FCB1010, a Zynthian and connect them with a midi cable.
I figured out how to MIDI learn one command to a footswitch. But I don’t see how I can send multiple CC messages with one switch. Can you explain how you do that?
