disturb wrote:You really should make an FR out of this soma, the whole idea would be really neat.soma wrote:I'm not a cakewalk user but I just read about Sonar 6, and it seems they are implementing something just like this.soma wrote:A good generic solution could be this option:
Send Selected MIDI Device Directly to Shown Docked Page Option
When option is active,
You can select a midi device(s) to send midi only to whichever components are shown in the docked page you are on, without having to hook up cables to those devices. Midi Cables still function as is. The device chosen is a separate midi bus dynamically and automatically routed. It is separate (but can be same device) from the device(s) selected for the Master input node. Option can be toggled On/Off.
This allows you to have limited midi knobs and assign them all to one instrument, then flip the docked page and create a whole additional set of assignments with the same controllers for the vsts and components docked there.
The controllers' output would be context sensitive based on the shown devices.
All that needs to be figured out is a good way to save these settingsI'm thinking this is like that.Active Controller Technology (ACT): dynamically re-maps effect, mix and instrument parameters to hardware controllers
Basically the simplest way to get this done in XT, would be to just link showing a dock to auditioning the instruments shown on that dock and only accept CC's from a controller when in audition mode... (then include a toggle button to audition all or just dock)
Also I started to think about it and there are a couple of other improvements that would be needed. Mainly, a sort of "latch mode" for receiving midi cc's. This new mode would only accept CC's from a hardware device once it passed an adjacent value from the last one it received, to prevent jumping when flipping back and forth between docks.
This would be needed because if you are switching what the controller is controlling from dock to dock, the knobs are going to be pointed at totally different values than they were the last time you were on a dock because you moved them while they were controlling something else.
An even better bonus would be a way to merge all the incoming CC's to a parameter without moving the knobs and sliders, so that you can merge GUI tweaks on top.
Eventhough i think it'd be better off working together with the hw midi output, so that controllers like the bcf2000 could update their values according to the page shown (can't recall what's the midi out status for v2...) ; and also i didn't get what you meant in the last sentence.
FR- improvements for midi control
-
- KVRAF
- 5350 posts since 8 Aug, 2003 from Berlin Germany
Moved from : http://www.kvraudio.com/forum/viewtopic ... 53#2054153
-
- KVRAF
- 2938 posts since 18 Jul, 2005
Resounding +1
-
- KVRAF
- Topic Starter
- 5350 posts since 8 Aug, 2003 from Berlin Germany
I had the idea first but it turns out Sonar stole it 
Anyway click here for an example of how one team implemented it.
http://www.cakewalk.com/Products/SONAR/Control.asp
Anyway click here for an example of how one team implemented it.
http://www.cakewalk.com/Products/SONAR/Control.asp
-
- KVRist
- 261 posts since 25 Jul, 2002 from UK
It wouldn't suprise me if they had some guy checking out this forum for FRs.soma wrote:I had the idea first but it turns out Sonar stole it
Anyway click here for an example of how one team implemented it.
http://www.cakewalk.com/Products/SONAR/Control.asp
I know I would. They bagged Rene.
+1
Charlie
ArtRage for Art | EnergyXT2 and Phrazor for Music | Blender for 3D
ArtRage for Art | EnergyXT2 and Phrazor for Music | Blender for 3D
-
- KVRist
- 30 posts since 14 Aug, 2006 from Bydgoszcz, Poland
What about automatic mapping? I mean, when you add a new instrument and want to control it remotely you must map a number of parameters manually... If i understand correctly, sonar will do the mappings for you (it's also like that in reason 3)...
I suppose this is implemented (in sonar) using predefined regular expressions or something like that - "map CC#12 to the first parameter which name contains 'cutoff' or 'cut'" etc. (btw, will XT2 have direct parameter handling so you dont have to map CC's and remember which number is what?) I think this would work nicely in most cases. But... well, that's not in EXT style
unless you have total control over all the rules of the auto mapping.
Another solution is to just let users create mappings from scratch and save them. You can then have different maps for single VST and switch between them and set the default map.
More clicks but you do it only once... And you know your mappings better.
I suppose this is implemented (in sonar) using predefined regular expressions or something like that - "map CC#12 to the first parameter which name contains 'cutoff' or 'cut'" etc. (btw, will XT2 have direct parameter handling so you dont have to map CC's and remember which number is what?) I think this would work nicely in most cases. But... well, that's not in EXT style
unless you have total control over all the rules of the auto mapping. Another solution is to just let users create mappings from scratch and save them. You can then have different maps for single VST and switch between them and set the default map.
More clicks but you do it only once... And you know your mappings better.
-
- KVRist
- 30 posts since 14 Aug, 2006 from Bydgoszcz, Poland
BTW, Live 6 also has that...
ableton.com/pages/live_6/whats_new/important_improvements
(dont have 10 posts so pasting as plain text)
ableton.com/pages/live_6/whats_new/important_improvements
(dont have 10 posts so pasting as plain text)
-
- KVRAF
- Topic Starter
- 5350 posts since 8 Aug, 2003 from Berlin Germany
I was thinking you could have Mapping "presets" to save and choose from. But I was also thinking there could be room in there for an in/out curves, lfos, meta data for searching, bells and whistles: whatever properties would be inherent to a vst parameter.Another solution is to just let users create mappings from scratch and save them. You can then have different maps for single VST and switch between them and set the default map.
But that's really not a great idea just a stab at how to get some consistancy while still having flexibility.
-
- KVRAF
- 3475 posts since 6 Oct, 2001 from europe-norway-oslo
Mapping presets is a must, but also on screen "preview" of your controller with knob assignments would help a lot. Some way how showing all mapped cc's has also been suggested.
cheers
jorgen
cheers
jorgen
-
- KVRAF
- 3475 posts since 6 Oct, 2001 from europe-norway-oslo
btw, extending the "dock page" functionality is any interesting topic as well. could be all sorts of features like midi mapping, mute/solo (for live presets) etc. An optional memo box at the bottom of each page could be usefull.
cheers
jorgen
cheers
jorgen
-
- KVRAF
- Topic Starter
- 5350 posts since 8 Aug, 2003 from Berlin Germany
Jorgen,
I agree completely that docking has huge potential for adding even more speed, clarity, and control.There is probably so much more that can be done with them. The midi mapping was the most immediate thing that struck me.
I'd love to hear what other people think can be done with docking. (I am starting to think of it in OO terms of aggregation and encapsulation...) Could something be done that helps you organize screen realestate(frames for showing >1 dock at a time)?Could we have docks for all sorts of stuff like, tabed browsing, tabed editors, or context sensitive editors, arrangements, mixers, etc
I like where you are going with developing a visual way to remind the user of what is mapped. The on screen "preview" is a good idea. How much screen space and cpu resources would such a view take up and when would it be visible?
Please tell us more about what you were thinking.
I agree completely that docking has huge potential for adding even more speed, clarity, and control.There is probably so much more that can be done with them. The midi mapping was the most immediate thing that struck me.
I'd love to hear what other people think can be done with docking. (I am starting to think of it in OO terms of aggregation and encapsulation...) Could something be done that helps you organize screen realestate(frames for showing >1 dock at a time)?Could we have docks for all sorts of stuff like, tabed browsing, tabed editors, or context sensitive editors, arrangements, mixers, etc
I like where you are going with developing a visual way to remind the user of what is mapped. The on screen "preview" is a good idea. How much screen space and cpu resources would such a view take up and when would it be visible?
Please tell us more about what you were thinking.
-
silicon/silicium silicon/silicium https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=33009
- KVRAF
- 1758 posts since 13 Jul, 2004
well, I currently betatest live6 and the contextual assignement is impressive: each "rack" (could be a docked page in ext)has 8 buttons that can be assigned to different params inside the rack. those buttons are contextually mapped to controller.is you select track containing a rack, 8 controllers are assigned to the 8 buttons, if you select anaother rack, the same 8 controllers are assigned to the 8 button of this other rack.
let's go further with ext: each dock page has a little zone at the bottom of the page showing 8 knobs (but we are in ext, so it's n knobs), then assign each knob with a drop down menu,and finally have a midi learn on each knob. let's called them "universal red knobs'. the learned controller stay the same on each docked page, but the params assigned to those knobs change. elegant, efficient, kick some ableton asses...
let's go further with ext: each dock page has a little zone at the bottom of the page showing 8 knobs (but we are in ext, so it's n knobs), then assign each knob with a drop down menu,and finally have a midi learn on each knob. let's called them "universal red knobs'. the learned controller stay the same on each docked page, but the params assigned to those knobs change. elegant, efficient, kick some ableton asses...
-
- KVRAF
- 1958 posts since 16 Jan, 2005 from France's Dirty South
What silicon/silicium described could be a good start, it's easy and straight forward.
A few things that come to my mind :
-ability to assign several params to each knob, each param with min/max, response curve
-display the vst(s) + param(s) names rigth under the knob to easily keep track of things (would be cumbersome to open the mapping editor each time)
-an option to flip through docked pages
A few things that come to my mind :
-ability to assign several params to each knob, each param with min/max, response curve
-display the vst(s) + param(s) names rigth under the knob to easily keep track of things (would be cumbersome to open the mapping editor each time)
-an option to flip through docked pages
-
- KVRAF
- Topic Starter
- 5350 posts since 8 Aug, 2003 from Berlin Germany
These are great ideas.
What I like:
-Each dock page has a little zone at the bottom of the page showing user defined knobs or x/y pads that are only active when dock is active
-The ability to assign several params to each knob, each param with min/max, response curve
-Display the vst(s) + param(s) and CC's in an context sensitive info box when the param or cc is updated
-option to display all or the dock's params and cc's being used with values in scalable/skinnable semi-transparent overlay on the screen.
-Can use midi to flip through docks
-Can midi learn directly from vsts' GUIs
-The ability free up more screen space for arrangements and main window etc. by showing only the virtual knobs and hiding the rest of the dock
-Have close integration between the dock in focus and recording/auditioning
-Can drag and drop from one dock to another
-Possibly have some mixing options for docks like mute/solo, increase/decrease all levels/pan, add a send to all, (bad examples but the principle is there)
-The ability to define multiple areas of XT's window (like html frames) for docks (so you can show more than one dock at a time) and/or main window, and/or mixer, and/or browser, and/or arrangement, live component, editors, etc. (This one I think will help the work flow sooooo very much)
-Changing the dock in focus could adjust other context sensitive frames. For example if you move a parameter that is recorded, the arrangement frame would show that track and the envelope editor would show the current clip for that track. Conversely, selecting that clip could also bring the dock with that parameter in it to focus.
What I like:
-Each dock page has a little zone at the bottom of the page showing user defined knobs or x/y pads that are only active when dock is active
-The ability to assign several params to each knob, each param with min/max, response curve
-Display the vst(s) + param(s) and CC's in an context sensitive info box when the param or cc is updated
-option to display all or the dock's params and cc's being used with values in scalable/skinnable semi-transparent overlay on the screen.
-Can use midi to flip through docks
-Can midi learn directly from vsts' GUIs
-The ability free up more screen space for arrangements and main window etc. by showing only the virtual knobs and hiding the rest of the dock
-Have close integration between the dock in focus and recording/auditioning
-Can drag and drop from one dock to another
-Possibly have some mixing options for docks like mute/solo, increase/decrease all levels/pan, add a send to all, (bad examples but the principle is there)
-The ability to define multiple areas of XT's window (like html frames) for docks (so you can show more than one dock at a time) and/or main window, and/or mixer, and/or browser, and/or arrangement, live component, editors, etc. (This one I think will help the work flow sooooo very much)
-Changing the dock in focus could adjust other context sensitive frames. For example if you move a parameter that is recorded, the arrangement frame would show that track and the envelope editor would show the current clip for that track. Conversely, selecting that clip could also bring the dock with that parameter in it to focus.