I’m diving into midi control of memory palace and will catalogue some observations as I run into them.
Currently I am using a cirklon for control, mp v18
midi note numbers trigger buttons with the button status associated with note length.
It would be useful instead or as an option to have a midi note number trigger on and the right adjacent note# trigger off
If this is possible, it would be more natural and lend itself to performance
I have not dived in yet but just trying to wrap my head around this. Does the button currently toggle via MIDI with note offs? I can see that with this approach it may be difficult to control things accurately in time or toggle multiple buttons on and off at the same moment. With adjacent notes it might be a bit confusing as the number of controls doubles and then it’s necessary to keep track of which notes are related. Keeping on/off on the same note message does simplify things. There is the possibility to use velocity. But why not just use CC values instead of notes I wonder? It’s best if the MIDI device controlling it actually knows the on/off status.
I have a Cirklon too, but I haven’t hooked it up to my video rig yet. So many options with MIDI and the CVIO / dmux breakouts.
yes currently the buttons toggle with note on/off respectively.
This is contrary to the way the buttons work on the unit. i.e. once activated button effects remain in on state until button is depressed again.
In a midi sequencer scenario(especially live) the current set up requires more midi information to be stored and limits the ability of the sequencer to activate the button functions on the mp in a pseudorandom and/or generative manner.
Example: spin: a 6 step bar with a button on signal on step 1 and button off signal on step 4.
In the current way the mp responds to midi notes and the buttons, note length determines the length of the engaged effect. This means that must be programmed into the sequencer which means more time programming and more midi data to store. Also the length the button affect was engaged in a pseudorandom mode would always be the same.
If the mp had midi note c4 trigger spin on and c#4 off, now running the sequencer running in a pseudorandom mode would trigger on and offs at different intervals. e.g. sometimes the spin effect would stay on for 2 steps and others 12 or more possible.
I don’t see remembering the note#s being a problem. They would go in order just like they do now except the right adjacent note# would be off to its respective on. And once you get these values programmed into your sequencer or controller, you are really not going to mess with it. I have midi gear with on/off buttons that are controlled in the manner I described.
cc# would be fine but it would require that a certain cc# value range be on and off which seems more difficult to change but who knows.
My suggestion is just that the mp buttons respond to midi control in the same manner as they react on the mp surface. I have tried to imagine many cases where one may use a midi keyboard or other controller to remotely trigger the mp buttons in the current configuration and it seems cumbersome to use in each case.
cc#'s would be better for my particular case as I could control 4 buttons on one pattern
but the note#'s are fine if they triggered the mp in the way the mp buttons operate stand alone.
I just need to use a new pattern for each button which is not that big of a deal.
The mp gets overwhelmed fairly quickly with moderate amounts of midi information coming into it.
When triggering the slider values via midi, the slider slew is not recognized. I am not sure this can be changed. The edirol v4 is the same with the cross fader being controlled, the cross fader is triggered in a “steppy” way because it is jumping to each of the 128 cc# values with no slew control. One the v4 you can set the cross fader to receive midi control on the pitch control # and get more smooth results but its is always an “effect” and never quite what you will get by manual control.
That is all to say, I expect a certain amount of limitation in midi control but the change I proposed would just be for the midi control to mirror the way the front panel controls on the mp already act.
I’ve implemented this request into V19. Do you want CC# control over boolean parameters as well?
MIDI control is very easy to modify or add if there’s something you want. The trick is just finding an effective way to navigate the settings in the UI. I am planning a global MIDI settings/monitor page and eventually a “subject -> verb -> object” style event list programming interface so that you can generate events in the system from any source. So for example, we could generate an “X Mirror On” event based on the value of X Position crossing a threshold of user defined 66%, etc.
Awesome. I am trying to think of cases where cc# control over the boolean parameters would offer anything. I am not sure if it is possible but if the cc# that controls a slider position could use the slew settings for said slider. The 128 increments makes control “steppy”.
One work around I have used with other devices in the past is to use the cc# for pitch as it has more resolution. I can also simulate a midi slew rate by using “tie” and “length” however if it could just use the mp’s slew settings it would be easier/intuitive to program.
I can add slews for CC values and CV inputs too. They do respond to the 14-bit Ableton spec, by the way. (MSB in CC #n and LSB in CC#n+32). So there’s 14 bits of resolution there if your controller can be set up to send that.
Sounds like this is going in a good direction. Using Ming Micro as an example, I find it very easy to look up the parameter I want to control since they are in a simple sequential CC list, including booleans (0 = off, 1+ = on). For me, I really appreciate simplicity and consistency having it all on CCs. One huge benefit of this is that I can store all these settings externally and send it all out at once like presets.
Ming Micro offers an option to use pitch for parameters that need finer control - that part I have struggled with because it only uses a couple hundred of the 16383 possible pitch values and is more difficult to debug if values are being received outside of that relatively minuscule range. It still gives you the option to use 0-127 CC if you’re ok with the steppy-ness. I usually bite the bullet and use pitch but it’s a pain in the ass IMO.
What I’m concerned about, is Ebbflos comment about MP possibly being overwhelmed with MIDI data. This is exactly what happens with Ming Micro, especially when it is receiving high resolution data. I control it with Teensy so I’ve had to be very careful to program in logic to minimize what I’m sending to it, basically measuring MIDI traffic and tossing the least important things out like recent adjacent values when things get thick, ignoring duplicates, etc. Ming Micro is unusable in many cases without implementing this. Could MP have some of this traffic control built in? 14 bit CC is only going to make the situation worse.
Memory Palace is a dual core ARM processor, it’s not going to be blinking at MIDI data any time soon! All the video processing is done in the FPGA, so the ARM is entirely free for UI/parameter/MIDI management.
I like the idea of putting booleans on CC#. Maybe we start those at CC#64, since CC#0-#63 are reserved for 14-bit transmissions.
Here’s what I can do… I’ll keep MIDI notes active as “event trigger” behavior, and CC# > 0 as on/off can just be a XOR invert with the current state.
That sounds good. Either is fine with me. In my experience the use of note# for boolean parameters is on old midi controlled(or partly controlled) audio mixers.
The cirklon does handle LSB in the same way, I think it is reserved for program changes.
For me though the linear parameter retaining its slew(s-curve,etc) setting when triggered via midi is optimal.
Sounds good to me.
Re traffic. Unless I’m misunderstanding it, which I certainly could be, MIDI overflow is a problem with the MIDI spec itself - there’s only so fast the data can move down the pipe. Eventually the buffer gets full and everything is backed up. Maybe there isn’t any way to remedy that on the receiving end. I’ve only handled it by sending less.
Interesting. Yes, I imagine Memory Palace has no problem receiving and handling MIDI messages as fast as they can be sent. Out of curiosity I just did some timing. A MIDI byte takes about 320uS, so in a message containing 3 bytes like a CC# update, that’s 3 bytes or just under 1ms per message.
The way Memory Palace works is based on a frame rate update. So MIDI messages are collected for 1 frame, and then during parameter update, the messages are processed and routed/summed with various parameter values.
So at NTSC frame rate the period is 33.3ms, meaning you could send up to 33 MIDI CC # updates per frame (the maximum update rate.)
If we want to update all 12 slider parameters at 14-bit depth, that’s 24 updates per frame. So no problem. Beyond that though, it does sound like you’re going to be limited by the MIDI transmission rate.
Now, we’re actively working at USB MIDI Host and USB MIDI Device drivers for Memory Palace, and I imagine lots of expansive possibilities there.
Yes, in my experience every device has limits but its fairly a great amount. Usually when I get a lock up on any device receiving midi it has more to do some major function change while receiving a bunch of midi data. However this is always in experiment mode and for performance you get it locked down. Many devices have a midi panic button for when this happens.
That addition of having the cv inputs hold onto the slew settings is awesome too.
I would use CC values < 64 as off, and >= 64 as on for buttons. That is kind of standard and avoids the problem of many controllers not being able to deliver a full 0 value when old, etc.
yes this would be a good thing for sure <64 off >64 on for buttons
with the
I can imagine it would be quite fun to make preset sliders that would turn on multiple buttons and set settings as it traveled from 0 - 127
I used to have a bunch of fun with using one slider to do multiple things split up across its full throw in Max/msp. Whether it was playing different drum sounds with or changing settings it made them feel very different than your standard slider.
instead of a preset button it would allow you to slowly change into a preset to some degree
if there was the ability to also save your current parameter settings via this event style programming interface you could do a button press to save and a very low threshold to return to current settings of all those parameters being changed that way you could slide in and pop out of your preset back to normal
or set up another slider as your “slide out of preset” back to whatever you had saved with the button press. Then if you had multiple presets setup this way you would just need one master return to previous parameter settings
fun to think about
I would use CC values < 64 as off, and >= 64 as on for buttons.
Yep, that’s what I’m going to do. Starting at CC#64 (first 32+32 reserved for 14-bit MIDI params.)
I’m going to switch MIDI notes to controlling media frame/delay frame offset, so you can do frame sequencing via MIDI.