Ideas for the user mode

[markusschloesser]

1. Step sequencer with 32 steps. Use vpot encoder press to enable /disable step and vpot encoder rotation for velocity or pitch (switchable, could also be a general p-lock) . Also together with the banking, a multiple of 32 could be implemented. Doable? Yes, I think so. But not by me. How? Clip API, set notes

[BilldarBagdar]

Yes! The Arsenal scripts feature a couple of really cool "step sequencer" modes that are very dynamic and fun to "play", and that is one of the reasons I practically begged for an SDK or something from NativeKontrol so I could get that same Arsenal functionality on the C4 (after I first asked them to "Arsenalize" the C4 and was told "if there is enough interest").

I suspect I know more than you do about programming generally. But, we are basically in the same boat as far as Python goes. Particularly the deeper one goes into Pythonesque esoterica.

I think a perspective one might take to implement such a user mode would be to think more about "clip control" than strictly "step sequencing". A one bar clip could be represented as any "power of 2" steps 1, 2, 4, 8, 16, 32 (whole note, half note, quarter note, etc) regardless of the clip's "piano roll" midi information. (It's a little easier to think about dividing an audio clip into an "arbitrary power-of-two" number of steps that are either on or off when the "sequence pointer" hits that step, but the same principle also applies to midi clips) You could also "edit" a clip's "start point" and the loop start/end points (in real time, while the clip is playing).

I can imagine though, it would be pretty cool to implement something like the Push2 (drum Instrument sequencer - any Simpler versus any Sampler) step sequencer where you can select the "step resolution" (whole note, half note, etc) and the display would update accordingly. Each encoder would "ping" (light up) when its step is active, and the "pings" would traverse the associated (1, 2, 4, 8, etc) encoders in time with the song tempo, and then when you turn knobs, it raises or lowers the "pitch info" of the associated midi note in the sequence "next time around". (or maybe you could select what parameter is tied to the knob turns, raising and lowering "velocity" instead of "pitch" for example. and I think it might be super cool if we could tie "device parameters" to those "sequencer knob turns" - for example having a sequenced "filter resonance" value that jumps around step-wise with the sequence. ...and what if you could "layer" sequence pages and navigate between them. You could have a pitch sequence, a velocity sequence, and a "device parameter" sequence all looping in time with the song and playing clip. (LOL - Imagination is easy, implementation can be a bugger)

a Step sequencer could be just one function in what could be called "Clip mode". So the script would have "Channel (Track view) mode", "Device mode", and "Clip mode" where the device and clip modes would always be associated with the currently selected "Channel" (mode). In that sense, we might need a way to activate "clip mode" from "channel mode" similar to the way "device mode" can be activated by clicking an encoder button.

Maybe this should be a separate Issue but for example, while two of the four buttons around the "black ellipse" work to switch the selected Track left and right in a session, the "slot up /down" buttons have not worked (like I expected, maybe something happens). I was expecting the "selected clip" on the selected track to switch up and down the "clip stack" on the Track in the session.

Just for starters, it would be cool to be able to switch selected Track in Channel mode (using Track L or Track R "ellipse buttons"), "Slot up or down" to a different "selected clip" on the Track, and then start or stop the clip (from) playing, all on the C4 without touching a mouse.

[BilldarBagdar]

...maybe some of the 12 "Send control" encoders in Channel mode could be repurposed to support "clip playing" features. Like one encoder for "clip start point", one for "loop start point", one for "loop end point", etc. and "encoder button presses" (on those repurposed encoders) could active other "clip mode" features or whatever...

[markusschloesser]

you seem to like the idea 😁 I also like step sequencers a lot but am covered atm. I have a Monome Grid 256. But I agree, a "clip mode" could be very useful. Will add this to the original list.

I suspect I know more than you do about programming generally.

You suspect correctly

But, we are basically in the same boat as far as Python goes.

I doubt that ;-)

I can imagine though, it would be pretty cool to implement something like the Push2 (drum Instrument sequencer - any Simpler versus any Sampler) step sequencer where you can select the "step resolution" (whole note, half note, etc) and the display would update accordingly. Each encoder would "ping" (light up) when its step is active, and the "pings" would traverse the associated (1, 2, 4, 8, etc) encoders in time with the song tempo

That's exactly what I had in mind even though I don't own a Push(2)

(or maybe you could select what parameter is tied to the knob turns, raising and lowering "velocity" instead of "pitch" for example. and I think it might be super cool if we could tie "device parameters" to those "sequencer knob turns" - for example having a sequenced "filter resonance" value that jumps around step-wise with the sequence. ...and what if you could "layer" sequence pages and navigate between them. You could have a pitch sequence, a velocity sequence, and a "device parameter" sequence all looping in time with the song and playing clip. (LOL - Imagination is easy, implementation can be a bugger)

That's what I meant with "p-lock"

a Step sequencer could be just one function in what could be called "Clip mode". So the script would have "Channel (Track view) mode", "Device mode", and "Clip mode" where the device and clip modes would always be associated with the currently selected "Channel" (mode). In that sense, we might need a way to activate "clip mode" from "channel mode" similar to the way "device mode" can be activated by clicking an encoder button.

"User Mode" for this? and within user mode have a "step sequencer", "Midi clip editing", "Audio Clip editing" etc?

Just for starters, it would be cool to be able to switch selected Track in Channel mode (using Track L or Track R "ellipse buttons"), "Slot up or down" to a different "selected clip" on the Track, and then start or stop the clip (from) playing, all on the C4 without touching a mouse.

As the up/down arrows navigate devices in "track mode", they could navigate clips in clip mode

[BilldarBagdar]

I knew "Slot Up" and "Slot Down" buttons on the C4 were mapped in one of the modes. You've confirmed they are used in "plugins/device" mode, but not "Channel mode". I agree, because those "Slot up/down" buttons are not used in "channel mode", they could be. The up/down buttons could navigate the "selected clip slot" on the "selected track" in channel mode. Then a user could intuitively use all four of those buttons in channel mode (in the sense that even if a user is thinking about "moving the selected clip slot left/right", it would just intuitively work for them. While under the hood (bonnet in UK) we know it's always the "track selection" moving left/right and the "clip slot selection" just comes along for the ride with everything else about the selected Track. A user will think whatever they think. Developers can only try to avoid making users "think too hard" to use the application they've developed...)

I'm imagining a performance situation that could flow like so:

In channel mode:

• switch selected track
• switch selected clip slot
• start Clip in selected Slot
• switch selected device (clicking the device's "channel mode" encoder button jumps to device mode)

In device mode:

• switch parameter bank
• adjust some parameter value
• switch back to channel mode (clicking the "Channel Strip Assignment" button)

In channel mode:

• stop Clip in selected Slot
• switch selected clip slot (wait for previous Clip to actually stop, or not)
• start Clip in selected Slot
• click same device encoder button to go back to device mode with same device selected

In device mode:

• You are still on the same selected device bank and parameter (unless those selections changed elsewhere?)
• The C4 "knows" what selected-parameter value is "current" when we entered device mode (this time? not only because we adjusted the value last time in device mode?)

Rinse and repeat. (or not, "repeat with small changes" more likely)

Such a flow doesn't even get into a "clip mode" really. All we would need other than the "Slot Up/Down" buttons in channel mode would be, for example, re-purposing the 12th "Send level" encoder in channel mode so it acts like the "Mute" and "Record Arm" encoders to Start and Stop (clockwise turn to Start) a Clip in the selected clip slot. That way, the "Clip Start/Stop" encoder button press event could still be used to jump to "clip mode". (However, button presses to "Mute/Unmute" Track, "Record Arm/Off" Track and "Start/Stop Clip" in selected Track slot" make more intuitive sense to me than knob turns. So maybe "jumping to clip mode" should only work by the encoder button press if the event is not going to be used for "Start/Stop" in that intuitive sense. It would be "not surprising" to users if both knob turns and button clicks worked to Mute/Unmute the Track, for example, and the same "not surprised reaction" would be true for Clip start/stop.)

We've sort of drifted off the topic of "Ideas for User mode". My first thought is we should start by just changing the name. What does a name like "user mode" imply? It implies the mode allows users to DIY (as it were) their own modal functionality desires using "user mode SDK tools" provided. I don't think we have any plans for creating any "SDK tools" for users to play with.

(except for maybe my dream of recreating the "Commander" app functionality in Live/M4L. Rabbit Hole: Wouldn't it be cool if the C4 graphics and "programming the C4" functionality like in Commander was the UI of a m4l device, and that m4l device knew about and could leverage this C4 Remote Script. You could "Open the device UI window" and in "performance" mode (versus "xml programming" mode) you could interact with the physical encoders and the m4l device GUI would update and vice versa. Now that would be a "user mode". In that "user mode" this remote script could "defer to the encoder mapping" found in the LOM as a property of the "C4 Field Marshall" m4l device, and the m4l device would provide the encoder mapping property value based on the "XML programming" users have done (the "layout" xml docs you create in Commander's "programming mode" are all about "re-assigning encoder parameters" where each "layout" is it's own set of "assigned encoder" parameters for use in Commander's "performance mode")) This description glosses over some possibly tough "programming issues", but in general, I think it's possible because all the pieces have been done before. Tying pieces together in the desired manner could still be a challenge though.

[markusschloesser]

not so sure about step sequencer anymore, because I don't think there is a need. One could just use a m4l device for that and then use the C4 in device mode for that m4l device ==> all steps automatically mapped to vpots. I already saw this happening in the "arp control" m4l device.

[markusschloesser]

Obsolete now, will continue tracking in #118