-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Capture rehaul and MIDI handling #1918
Labels
Comments
unfa
changed the title
Master keyboard integration / Piano Roll & Automation improvements / Capture rehaul
Capture rehaul and MIDI handling
Apr 3, 2015
Closing as duplicate of many other bug reports. Please chime in if I've missed something. 👍 |
This was referenced Apr 10, 2015
Closed
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Preface
It started when I got a few ideas where LMMS could better use so called "master keyboards" or musical keyboards in general. The idea is as always - to save user's time and do stuff for him, to keep him focused on the music, not breaking world records for mouse clicks per minute.
However it turned out I have much more on my mind, and the issue goes into rethinking the process of capturing MIDI and audio (not yet implemented) data into LMMS and making use of MIDI data in a smarter way.
Issues
Recording notes and automation
Problem
LMMS allows to use any MIDI device as input and/or output to each instrument. That's nice for live operation I'd say, where I can route different controllers to different instruments or even filter that via MIDI channels (16 instruments driven by one keyboard etc.).
What I lack is a "master MIDI controller" option, that'd allow the user to select a MIDI device he wants to use as a"fallback" or default MIDI input for Piano Roll and Automation data recording.
Why do I think we need this? Time of course.
The current workflow for recording notes for two (let's call them A and B) instruments is as follows:
And with a master MIDI controller option it'd look like this:
Also, the Piano Roll and Automation editor workflows are different - you don't have "REC" button in Automation editor, and you need to arm/disarm automation patterns for recording - instrument clips don't have that. Why instrument and automation regions work differently? Can we make this consistent? I fell there's even better way of handling all this recording thing.
Solution
My idea is to remove recording controls from Piano Roll window and place them in the main transport pane. The REC would be a toggle button, also each track: instrument, automation, audio would have an additional "REC" toggle LED button similar to the "ON" and "SOLO" controls we have there. No per-region record-arming for automation, instrument or audio clips.
In the settings window there could be unified "Capture" tab with panels for: instrument, automation and audio capture. The user could select a default device for each capture type (notes, auto, audio).
This could also cover capturing multiple tracks of the same type at once.
For audio: for example JACK ports system:capture1,2 for 1st audio track, ports 3,4 for 2nd, 5,6 for 3rd etc.
For automation: device(s), MIDI channel(s), CC1, CC2, CC3... or CC1-8 or CC4,6,8,10 whatever.
For notes: device(s), MIDI channel(s),
When global REC toggle is disabled, the input is ignored, when user opens Piano Roll, the first notes capture device on the list is used as input for corresponding instrument - so the user can try some notes in the piano roll to hear and see them (keys being pressed in the GUI).
This way the user could setup LMMS to smartly use his studio gear depending on the "situation on the field". If the user wants to record automation for 3 knobs while playing a synth and singing, he hows that the three faders on his keyboard will be used for that in order, after toggling "REC" he can move the faders to try if it works before he presses "PLAY", play a few notes, say something to the mic etc. Also LMMS could feature some device-sepcific presets we as a community can produce for the gear we own, so the user will have sane defaults in the "Capture" tab from the start.
What about the wheels and pedals?
Apart from notes and automation, MIDI controllers also provide pitch-bend wheel, modulation wheel, sustain pedal and expression pedal to handle. I've got no idea how to handle this stuff. Help!
Transport control via MIDI/MMC
Many control keyboards feature dedicated transport controls, that send some messages that can be used to keep the user at the keyboard, without the need to use mouse or QWERTY keyboard. Not to mention all the MIDI control surfaces, or even devices dedicated to control a DAW. I guess we could learn from Ardour in this regard.
Using drum pads
Per instrument note ranges
Right now using drum pads in LMMS isn't an easy thing. AFAIK unless you have a perfectly fit soundfont or Zyn patch, they are pretty much useless. I think LMMS needs to provide another way to filter MIDI data for instrument input: note range. This way, a user could add a bunch of drum samples, assign them to a drum pad MIDI controller, select first drum sample instrument, hit the first drum pad, and then click on "min" and "max" buttons to set the MIDI-notes range that this instrument will accept. This is how it works in ZynAddSubFX, and I think it's great.
Dispatcher instrument
Another idea is to create a new instrument plugin that'd allow the user to map instruments to individual notes or note ranges on the piano roll or physical keyboard/pad controller.
The instrument would present a customized piano roll with custom names for each note: "Kick" instead of "C-3" etc. The Dispatcher instrument would have a configurable list of notes/note-ranges and instruments that are driven by the selected note(s). For example:
Outro
I guess we can find a bunch of people in our community who own a master keyboard/DAW control surface or other gear that we could make LMMS aware of. I'm tempted to ask you about what device(s) you have and would want to help configuring LMMS to use them, but it's too early for this stage now.
Do you even think what I wrote makes sense? ;)
The text was updated successfully, but these errors were encountered: