[feature request] New midi control mod params: Rec Arm, Solo

[muranyia]

On a rather selfish note, I'd love to be able to send these mods from my shiny new (AKAI APC MINI) control surface:

• Arm for Recording
• Solo

[F0rth]

Waiting OSC avaibility, I use https://github.com/Excds/seq24-launchpad-mapper for my launchpad mini.

[muranyia]

Thanks @F0rth I've found that and hacked my LED feedback based on it.

"Solo" might not even be necessary as we have Replace. It would make sense if it allowed a temporary solo which could then be released and the original state would return. I don't exactly know how this would work, however.

[mxmilkiib]

A MIDI mod to toggle the recording of incoming MIDI data would be an amazing step toward not having to touch the mouse. I guess a mod for MIDI pass through would also be required?

[muranyia]

And then, actually, Start/Stop via MIDI would be something very valuable.

[ahlstromcj]

Okay, I finally studied MIDI Control enough to feel confident in making changes to it. I've added "extended" MIDI controls (from 74 to 83) and have the first control, MIDI playback (stop/pause/start) working. To test this code, you will have to "git checkout" the "wip" branch and build it.

I also documented how to test the new feature in Section 8.2 "Sequencer64 "rc" File / MIDI Control Extended Automation Section" of the sequencer64-doc project. You will have to "git checkout" the "cja" branch and view the existing PDF file there.

There are entries for performance recording, solo, and thru, but events at work have prevented me from getting to those yet. Another side issue is that I want to create one more executable, something like "seq64cmd" so that it can run without a GUI, and be usefully controlled via MIDI.

Anyway, please test and comment on the new feature.

[mxmilkiib]

Just a quick try with wip and MIDI pause:

MIDI pause works fine on start

There seems to be a state mismatch between a pattern being black and the "Sequence dumps data to MIDI bus". Turning on/off it in the editor window turns it on/off in the main window, but turning on/off in the main window doesn't turn it on/off in the editor window. Not actually sure if that's new though, more paying attention to figure out what causes the following.

Clicking "incoming midi passes through" and the pause midi control stops doing anything. Unclicking it and the app stays unresponsive to midi pause.

Click "record incoming midi data" and pressing midi pause (or any other MIDI key/knob/fader) advances the pattern by one note, with keys adding a note but CC buttons/pots/faders (including MIDI pause) advancing the red line but not being recorded as a CC event.

Edit; the last one is half expected at this point, though being able to record seq64 command midi as a pattern would be neat as it could add another dimension of 'expression', though I guess this might require something like a separate control input channel (with an internal control bus to route that would turn a pattern into a meta/control pattern)?

[ahlstromcj]

Thanks for the report. I will look at it this weekend. Gotta keep those states in sync!

-------- Milk Brewster 04:08 Fri 24 Mar --------

Just a quick try with wip and MIDI pause:

MIDI pause works fine on start

There seems to be a state mismatch between a pattern being black and the "Sequence dumps data to MIDI bus". Turning on/off it in the editor window turns it on/off in the main window, but turning on/off in the main window doesn't turn it on/off in the editor window. Not actually sure if that's new though, more paying attention to figure out what causes the following.

Clicking "incoming midi passes through" and the pause midi control stops doing anything. Unclicking it and the app stays unresponsive to midi pause.

Click "record incoming midi data" and pressing midi pause (or any other MIDI key/knob/fader) advances the pattern by one note, with keys adding a note but CC buttons/pots/faders (including MIDI pause) not being recorded as a CC event.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/56#issuecomment-288994741

-- Time to be aggressive. Go after a tattooed Virgo.

[ahlstromcj]

So, I fixed the mismatch between the mute state in mainwnd and the "dumps data" button in seqedit. That bug comes from seq24.

And I fixed seqedit so that the "dumps data" state only blocks MIDI control when "is dumping". User stazed fixed it it his seq32 fork (also on github).

But disabling MIDI control while dumping seems to be a deliberate feature, preventing the MIDI control event from being transfer to the MIDI device doing the playing. I will think more about that.

Haven't had a chance to play with the "recording incoming midi data" issue yet. Won't get to it until tomorrow. But you can check out the latest wip and see what you think. It also adds the 2 decimals of precision for beats/minute requested by another user, but that fix isn't yet official either.

[ahlstromcj]

Looking at what happens with inputting MIDI control information while recording, what happens makes sense, and I suspect if you use the "Event" button in the "Pattern Editor" (seqedit) to select the events you are using as control events, you will see those events recorded. I see them in my sequencer-doc example where I assigned notes from 0 to about 11 as start, stop, pause, bpm-up, bpm-down, bpm-page-up, and bpm-page-down. It could be an option to ignore events during recording if they are found to be match in the midi-control-event function.

I have had requests to be able to provide a Tempo track and a way to record a live MIDI performance (where the pattern trigger actions are recorded). Perhaps there's a way to fold all of this into the Song/Performance editor. Something to think about.