sequencer64
sequencer64 copied to clipboard
midi control out
Is there any possibility to have midi outputs for the controls? i want to "print" the state of the patterns to my apc mini.
@ahlstromcj you saw this?
Yes, still tied up, merged Jack support to master but going to soccer game now. So much to think about!
On Feb 22, 2017 5:12 PM, "Georg Krause" [email protected] wrote:
@ahlstromcj https://github.com/ahlstromcj you saw this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/58#issuecomment-281821622, or mute the thread https://github.com/notifications/unsubscribe-auth/AHnVqKXlKUi0ukmrJZTzW-1RANhg24Prks5rfLLqgaJpZM4L71sy .
so i assume it isnt possible right now? just wanted to ask if i oversee something ;)
btw: buildung the new master right now to test the midi stuff, bug reports are on the way. have fun at your game @ahlstromcj
If you can, try to track down a "programming", "midi", or reference manual for that device. Apparently AKAI does publish a MIDI sheet for it, that I can tell. Thanks!
i can send it later. but wouldnt it be better to built something which works for more controllers?
I hope they all have the same mappings (like General MIDI), otherwise it could become a bit involved.
I think mappings differ from device to device. They'll have be set up in the usr file.
i see it like @muranyia, all those controllers have specific mappings. my apc mini sends note on/off instead of control changes, so we need a system like the midi mapping for incoming midi ;)
That feature would be awesome for controllers like the APC mini or Novation's Launchpad.
@ahlstromcj I don't think there is a standard. Here is the spec for the Launchpad : https://d19ulaff0trnck.cloudfront.net/sites/default/files/novation/downloads/10529/launchpad-mk2-programmers-reference-guide-v1-02.pdf
So much to think about for this little project :-) Work life very hectic.
Starting to work on updating sequencer64-doc for the new JACK support.
Any news on this feature? I was going to request the same functionality, since I am planning to build my own midi controller matrix using an Arduino platform. I am ready to contribute to the implementation if I manage to understand the code base, and if someone can point me to the right place to put this feature.
Would be interested too. Maybe just add another "table" in the rc file like for the inputs to define what is going to be send on a specific event?
Guys, in the meantime, you can use mididings to build a script that feeds back to your controller.
@muranyia I have used mididings to do similar stuff in the past. However, for a decent interaction with a controller such as lighting up the buttons corresponding to the active tracks, this script would have to be aware of the mute groups. For one-shot, I don't see any possibility without integration directly inside sequencer64.
@georgkrause Yes, this would be the right place to describe the midi event configuration. But I am rather wondering where in the source code to put this feature. Reading (and understanding) other people's code is not so easy...
Potentially integration via the openAV-Ctlra library might be worth considering?
@ahlstromcj - good luck with your exam on Friday! do ignore us for the now ;)
@muranyia this would only work if only one controller is setting the clip state, but would be possible (+ the mentioned mute groups)
@igorangst i think if you ask @ahlstromcj he would be happy to answer this question ;) it might be an good idea to create a new class since the output of midi control data is not implemented at all at the moment. but i never looked at the code of sequencer64
OK, I took some time to have a more serious look into the source code. I think I can come up with a first implementation to spit out MIDI events that notify a controller of some interesting things happening. At this time, I could only test this with a small Akai MPD pad, which takes NOTE ON/OFF events to light up the pads. Also, I would like to know, which kind of events should be notified. So, please give me some feedback on these two points:
- What kind of MIDI events are needed?
- NOTE ON/OFF
- Control change (CC)
- What else?
- What should be notified?
- Pattern start/play
- Pattern stop/mute
- Pattern queued?
- Transport events (start, stop)
- Maybe a metronome tick at quarters?
- What else?
Thanks for your feedback!
@igorangst great! Maybe i van jump in and help out a little.
-
How about copying the midi in method of seq64? There you can set the midi status byte and the two data bytes and using this you could display nearly every possible midi message.
-
The aim should be to let the controller display states and notify it when a state is changed. So i would list some stuff I need display:
- patterns state (on apc mini maybe blinking of queued, but later...)
- Queue mode state
- Replace mode state
- Is something stored in snapshot 1/2
Glad to hear someone is interested in doing this! I'm still wrapped up trying to get the Qt build in decent shape.
One thing to make sure is to let the perform object do the work. I've been trying to migrate as much functionality as possible out of the user interface.
If you feel up to it, stick all the functionality into a class the perform can use, and perhaps leverage the sequence class. Just tossing out ideas.
Anyway, keep us posted. Nice to get some additional help! I don't have any MIDI pad to test on :-(
-------- Georg Krause 16:59 Tue 27 Mar --------
[1]@igorangst great! Maybe i van jump in and help out a little.
1. How about copying the midi in method of seq64? There you can set the midi status byte and the two data bytes and using this you could display nearly every possible midi message.
2. The aim should be to let the controller display states and notify it when a state is changed. So i would list some stuff I need display:
* patterns state (on apc mini maybe blinking of queued, but later...) * Queue mode state * Replace mode state * Is something stored in snapshot 1/2
— You are receiving this because you were mentioned. Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.
Reverse link: [4]unknown
References
Visible links
- https://github.com/igorangst
- https://github.com/ahlstromcj/sequencer64/issues/58#issuecomment-376599111
- https://github.com/notifications/unsubscribe-auth/AHnVqK_cD6hRLLtxcdSBP_GVYqo12twiks5tinAEgaJpZM4L71sy
- https://github.com/ahlstromcj/sequencer64/issues/58#issuecomment-376599111
-- Your talents will be recognized and suitably rewarded.
Hi, I started working on this feature. You can check out the branch midictrlout in my fork.
To enable the feature, run
./configure --enable-midictrlout
For the moment, the midi control output is hard wired to output port 15 (this will be moved to the configuration). In the sequencer64.rc file, there is a new section [midi-control-out]. For now, there is only feedback on sequence state. For each sequence, you can set up four events with the typical syntax (e.g. [1 0 144 36 127] for enabled: note on event with pitch 'C' and 127 velocity). The four events are sent on arm, mute, queue, and delete, respectively. For now, there is 32 rows (hardwired, will be made variable). Also, all events are wrt the absolute sequence number, so no support for swapping the screen set. Anyway, this is just the start, and it works fine for me :-)
Please give me your feedback. Any bugs?
What should be the behavior for swapping screen sets?
- None, use absolute sequence numbers
- Reflect visible screen set (display in sync with the seq64 window)
- Refresh only on setting the playing screen set
There are more events coming:
- Queue modifier
- One shot modifier
- Replace modifier
- Play, Stop, Pause
- Snapshot 1/2 active
- What else?
Great news! I will check it out ASAP and give you some feedback. If you can, provide a poop-sheet that describes what-to-do and what you'd see. I don't yet have a MIDI pad, so I can't really try it out. If you're familiar with Doxygen, you can make a *.dox file in doc/dox and add it to the INPUT value in doxy-notes.cfg. Your call.
I am going to be checking a new configure.ac into the qt5_reconcile branch; it was adding gtkmm as a dependency of the non-GUI libraries.
Anyway, I gotta cool off from my bike ride, get some food. :-)
-------- Igor Angst 20:30 Tue 03 Apr --------
Hi, I started working on this feature. You can check out the branch midictrlout in my fork.
To enable the feature, run
./configure --enable-midictrlout
For the moment, the midi control output is hard wired to output port 15 (this will be moved to the configuration). In the sequencer64.rc file, there is a new section [midi-control-out]. For now, there is only feedback on sequence state. For each sequence, you can set up four events with the typical syntax (e.g. [1 0 144 36 127] for enabled: note on event with pitch 'C' and 127 velocity). The four events are sent on arm, mute, queue, and delete, respectively. For now, there is 32 rows (hardwired, will be made variable). Also, all events are wrt the absolute sequence number, so no support for swapping the screen set. Anyway, this is just the start, and it works fine for me :-)
Please give me your feedback. Any bugs?
What should be the behavior for swapping screen sets?
- None, use absolute sequence numbers
- Reflect visible screen set (display in sync with the seq64 window)
- Refresh only on setting the playing screen set
There are more events coming:
- Queue modifier
- One shot modifier
- Replace modifier
- Play, Stop, Pause
- Snapshot 1/2 active
- What else?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/58#issuecomment-378387662
-- Good night to spend with family, but avoid arguments with your mate's new lover.
Haven't had time to look at much, just a couple quick comments before I head to work. First, it would make your new files easier to read if you piped them through "expand --tabs=8" to get rid of the tabs.
Second, you could make an overload to midi_control_out::set_seq_event() to accept the int array directly so that
event ae, be, ce, de;
if (a[0])
{
ae.set_channel(a[1]);
ae.set_status(a[2]);
ae.set_data(a[3], a[4]);
mctrl->set_seq_event(i, midi_control_out::seq_action_arm, ae);
}
becomes simply
mctrl->set_seq_event(i, midi_control_out::seq_action_arm, a);
I.e. let that function deal with the details.
Anyway, if I get too overbearing let me know. I will try a build tonight, or at worst, this weekend. Thanks!
-------- Igor Angst 20:30 Tue 03 Apr --------
Hi, I started working on this feature. You can check out the branch [1]midictrlout in my fork.
To enable the feature, run ./configure --enable-midictrlout
For the moment, the midi control output is hard wired to output port 15 (this will be moved to the configuration). In the sequencer64.rc file, there is a new section [midi-control-out]. For now, there is only feedback on sequence state. For each sequence, you can set up four events with the typical syntax (e.g. [1 0 144 36 127] for enabled: note on event with pitch 'C' and 127 velocity). The four events are sent on arm, mute, queue, and delete, respectively. For now, there is 32 rows (hardwired, will be made variable). Also, all events are wrt the absolute sequence number, so no support for swapping the screen set. Anyway, this is just the start, and it works fine for me :-)
Please give me your feedback. Any bugs?
What should be the behavior for swapping screen sets?
1. None, use absolute sequence numbers 2. Reflect visible screen set (display in sync with the seq64 window) 3. Refresh only on setting the playing screen set
There are more events coming:
* Queue modifier * One shot modifier * Replace modifier * Play, Stop, Pause * Snapshot 1/2 active * What else?
— You are receiving this because you were mentioned. Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.
Reverse link: [4]unknown
References
Visible links
- https://github.com/igorangst/sequencer64/tree/midictrlout
- https://github.com/ahlstromcj/sequencer64/issues/58#issuecomment-378387662
- https://github.com/notifications/unsubscribe-auth/AHnVqDIjThoCscXuTec054KkkbPldJWwks5tk9vegaJpZM4L71sy
- https://github.com/ahlstromcj/sequencer64/issues/58#issuecomment-378387662
-- Debian Hint #27: Regularly verify your backups. You are keeping backups, right? Right? If not, start with tar(1) or dump(1).
@igorangst Thank you for picking this up. I'd prefer messages tied to the current screen set, and refresh when changed. Using a 8x8 AKAI APC MINI, willing to test!
+ignoangst: Igor, I will be looking into merging your code soon. Finishing up loading Cakewalk WRK files first, in the qt_reconcile branch. Also see jfrey-xx's note above
Hi, I didn't have time recently to get on with the midi output code, since I was working on my personal seq64 fancy RGB illuminated arcade button controller board :-)
There are still some bits and bytes missing, and I had some very bad crashes while testing, which I did not chase down. I hope to get on with debugging in two weeks or so.
I've just realised having MIDI out of pattern status comes very close to solving something I've been mulling for a while now; how could one use sequencer64 patterns to control MIDI/audio routing in conjunction with Carla, its internal plugins, and the few do-one-thing MIDI filter collections like midifilter.lv2 & Piz MIDI.
What I would like to do is have a "Drum parts" set with single-instrument-of-percussion drum patterns that combine well when they are all turned on. *
Then a "Drum instruments" set with patterns that, when turned on, would "send" the drum MIDI to one instrument plugin, so there could be an "alvdrums black" pattern, an "alvdrums red" pattern, maybe some for some for drum soundfonts, so I can easily switch or layer up the sound. *
The "control" patterns could be blank, but turning them on and off, with the new MIDI control out feature, would send a MIDI event that could be utilised to automate the MIDI routing plugins in Carla.
* This example is a simple picture; I would actually send parts out on different MIDI channels so MIDI effects can be applied separately to each, and this would be controlled similarly with a "Drum MIDI FX" set (with like "MIDI delay", "Probabilistic drop", etc. patterns.) that would appear after the parts set and before the instruments set. I'd then also have a "Drum Audio FX" set, and then repeat with sets for non drum parts.
I say very close because it would require the output of set change details out so as to automate the automation of the automation, or something like that :)
(Previously I had tried patterns full of CCs which made things slow and plugins unstable, and notes-the-length-of-a-pattern don't just come on if the pattern is activated half-way through)
First, kudos for a great software, it has almost everything I need! :)
I've tried @igorangst fork just now, configured it with
./configure --enable-midictrlout
I'm aiming at triggering some patterns/sequences with my novation Launchpad Pro. I have been able to use the [midi-control] for a 8x4-grid and an 8x8 grid using mididings, but the [midi-control-out] resets itself to all zeroes [0 0 0 0 0 0] on all 0-31 fields when i quit seq64 if my data looks like this:
0 [0 0 0 0 0] [0 0 0 0 0] [0 2 144 81 16] [0 0 0 0 0]
[..]
31 [0 0 0 0 0] [0 0 0 0 0] [0 2 144 58 16] [0 0 0 0 0]
It had to do with me not enabling (on/off-ing) the entries. When I put a 1 to enable the entries, they do not reset.
To send flashing green when queued I should use a row like
0 [0 0 0 0 0] [0 0 0 0 0] [1 2 144 81 16] [0 0 0 0 0]
where 2 is the MIDI-channel that is mandatory for getting the button to blink. However, when I quit seq64 the 2 is gone. I see that the control out is hardwired to MIDI-channel 15, where can I change this in the code?
This is really the only thing left - in an otherwise great (!!) piece of software - that stops me from using it in a live setting. I'm happy to test, however I'm not a C-developer..
Hi, I confirm that there is a problem with inactive entries not being saved and thus being reset to 0. It has been some time that I worked on this, and I'm really happy that there is somebody out there ready to give it a try with a real piece of hardware. I will try and fix this as soon as I can spare some time. It is quite possible that I didn't implement the channel, since I only use channel 1 in my hardware. As far as I remember, 15 is the number of the (ALSA/Jack) output and does not refer to the MIDI channel.
Awesome! I'll change the m_buss(2) parameter in libseq64/src/midi_control_out.cpp back to m_buss(15) then. Wingin' it a bit... :)
If I may make a wish list it would be to have the grid on the Launchpad Pro reflect the grid in Sequencer64, maybe with some sort of translation table between the default colors in Seq64:
- Red
- Green
- Yellow
- Blue
- Magenta
- White
- Dark red
- Dark Green
- Dark Yellow
- Dark Blue
- Dark Magenta
- Dark Cyan
- Orange
- Dark Orange
That would (in my mind at least) allow for e.g. setting a 3-color scheme for the controllers that does not have full RGB-color LEDs, just by adjusting the color codes. Also, I would not use the Red and Green colors (why, I hope will be apparent below), and may want to translate them into some other colors instead.
I would also like Sequencer64 to mimick the behaviour of the Launchpad when used with Ableton Live (which I have never done, just seen videos). That means that
- When queuing a sequence, it should be flashing green. (MIDI-Ch 2, NoteOn, Pad XX, Color)
- When playing a sequence, it should be pulsing green. (MIDI-Ch 3, NoteOn, Pad XX, Color)
- When arming a track to record, it should be flashing red. (MIDI-Ch 2, NoteOn, Pad XX, Color)
- When recording in a sequence, it should be pulsing red. (MIDI-Ch 3, NoteOn, Pad XX, Color)
Stopping these requires a send of a (MIDI-Ch 1, NoteOn, Pad XX, Color) to the Launchpad Pro.
It is also possible to light several LEDs with a single SysEx-message on the Launchpad Pro, further detailed in the programmers reference but that might not be a way forward for other controllers, so maybe it's best to stick with MIDI messages.
Also, the pad note numbers seems to vary wildly even within the Launchpad family of controllers...