honestly, i can tell you after having tried all day (we have too much time, at the moment… ) , having a bold/long press coded in a simple one is not as terrible as i would expect…
I noticed it’s important to map short/bold select and short/bold snapshot, absolutely. One for layer post-editing, the second for load/save snapshot page, you can reach only with bold press.
Short/bold Layer are second in priority, but serves layer switching and it’s somewhat important in single layer setups.
Back switch can stay single.
I’ve not played in this area in a while. I will see if I can get The Motor61 controlling the expected behaviour for the Audio Recorder. ( Not sure how to do the MIDI recorder control except via a change of MIDI environment using MIDI Profiles).
These don’t seem to be standard MIDI Machine control codes, presumably Behringer has just kept it simple and highjacked some of the undefineds.
119 Would Toggle Audio Record
118 Would Restart Play of current selected audio from Start.
120 would Start Loop Play.
Controlled from the MIDI channel 2 ( Channel 3 in the Human world)
But it seems to do something!!!
No MIDI Rules …
The Play and stop buttons function as expected, but repeated presses of stop produce .
ERROR STOPPING MIDI PLAY
‘NoneType’ object has no attribute ‘pid’
Interestingly it also controls zynthian-touch.local as well across QMIDInet
That’s quite valid! I confess I was just going for a future-proof feature mapping (zynthian encoders - impulse knobs/buttons), but it is true, i don’t use more than 6 buttons on “daily” use. It’s just that I’ll always have that feeling that there’s something possible with the software that I can’t really access that easily
I wouldn’t say it’s a top priority, at least for the impulse - there’s buttons/pads aplenty. But I do second that I use snapshot/select bold/short presses more than the layer/back ones. That said, I’m definitely not as frequent a player as others here, so use cases may differ!
Don’t remember any discussion about it. I think that would have been the original concept, as I was thinking of how to work entirely without encoders, and I think we added mouse control ( Well turned the cursor on anyway) so I started to use that as my GUI control, so would have moved on to that, then we got into using GPIO pins to allow selection of functions, then we got involved in Keyboard over USB as that was the easiest way of adding nicely formatted controllers ( I use foot swithes that behave like ASCII keyboards), an so the concepts got implemented but possibly not refined.
This is already a hugely customisable little beast, and it does so much more than I’ve been able to explore. But we’ll always find different use cases, specially if we have to reorganise space to accommodate office working that takes over the space previously used as a studio… Hence, trying to make do with less gadgets
Hi Ivan,
there are a lot of ideas for solving this problem.
I try to make a difference between editing and playing. With the impulse, we have 25 patches. So it is possible for me to use one for editi-purposes and the other for playing.
Now I am working on a playback-controller with an old R3. That will send all needed commands if it’s ready. (time is no question…)
another idea is to use the bulk-dump feature of the impulse. I think it could be possible to send and receive bulk dumps to the R3 and then we have uncountless patches.
But you are right. If we have transport-knobs, they should work like transport-knobs, with the possibility to change between audio and midi. I think that’s only a question of the time. And the guys here are the best
On impulse it’s the only choice for transport buttons - MMC or CC. As expected, CCs are different between devices, but it’s fine.
So, i don’t know if Midi filter totally excludes master channel for some reason… if it’s an issue, could be a lot easier doing routings for these buttons,. practically everything would be possible.
You can change the behaviour of transport keys on the ROTOR. They can work in 3 different modes, being CC one of them. You also can use MIDI MMC and MIDI System Real-Time, the later is currently implemented (but quite untested) on zynthian. Simply change the MIDI transport mode from the ROTOR config menu and enable system messages on your zynthian.
No, Raspberry Pi 3B. As I realized that the R3 cannot play the pianotec sounds very good, the R4 was offered, with much better equipment. So I decided to make sounds with the R4.
I have had a Morningstar M6 (wonderful piece). It was stolen …
But now I have the time to program a little and learn new things. If it’s ready I think during the performance I can play with my hands at the keys and to control with my feet.
But in the editing situation the impulse is unbeatable.
Hi @jofemodo, I tried to use MMC but Zynthian recorders don’t react. I saw it working from DAW accidentally, time ago. Regarding master channel masked on midi filter rules, maybe could be caused by this. I temporarily solved it mapping transport cuia on a different channel, but if MMC works, could be better.
I encountered another issue with second zynthian (just rpi 4 and touchscreen) but will do a new topic
This is how I mapped the transport buttons on Novation Impulses (specifically select up/down, play audio, stop rec audio, stop all sounds and start record audio):
MAP CC#112 => CH#15 NON#52
MAP CC#113 => CH#15 NON#53
MAP CC#114 => CH#15 NON#25
MAP CC#115 => CH#15 NON#26
MAP CC#116 => CH#15 NON#12
MAP CC#117 => CH#15 NON#24
Impulse will send those CC on whatever channel the keyboard is pointing at, and Zynthian’s Master is set to 16 (the default). I don’t quite get why using a filter target channel of 15 works - but it does
One problem I see with the above is that these transport buttons show up in the MIDI log as having a value of 0 and 127 (equivalent to notes on and off). And so, Zynthian receives each command twice. This makes toggle commands pretty useless, as Zynthian reverts to the original state on the second CC. And as mentioned before in this thread, this is only an issue as Impulse’s transport buttons can only be swapped from MMC to CC, they can’t be set to single/toggle/step or configured for specific events and channels (as the other 9 buttons, sliders, 8 knobs and 8 pads can)
That said, all the other commands seem to work fine for me (including the specific mappings above). One thing I’ve noticed - if you press Stop recording while it’s not recording, Zynthian shows an error message. But we can just wait 5 seconds and it goes away. Is it a bug or a feature?
The midi filter rules are 0 based…like the MIDI protocol.
Unfortunately in the 80s we had to save bits and bytes and couldn’t afford enough to neglect the 0.
Actually the midi devices in the world should have educated the humans that 0 is a valid channel.
Saying that…15 is 16
Thanks for clearing that up @mheidt - I’m perfectly fine with 0-based indexing (specially if there’s a rationale for it, as it seems to be). It’s just I thought I had used a filter set up to channel 1 that received a controller’s events on channel 1, not on 2 - but I can’t replicate it now I did too many experiments, I think my mind played some tricks on me!
BTW, I fixed the MIDI filter for allowing to MAP/IGNORE Master Channel and Program Change messages, so you can now re-map all the Master Channel messages (CUIA notes, etc.) to whatever you like (this doesn’t include SysEx messages like MMC, etc.)
I did too many experiments, I think my mind played some tricks on me!