• SONAR
  • Me patiently waiting for Track to Track Routing in Sonar (p.6)
2015/09/01 11:04:13
PilotGav
KPerry
GaryMedia
 
I quite agree with Beepster who says "Honestly I don't really like the workflow of having all my busses mixed in with my track strips (that's just me). Too messy and confusing."
 



+1 to this.
 
I also think there is a definite advantage in thinking about busses and folders differently: folders are for organisational purposes and should be focused on and optimised for that; busses are for mixing and should be focused on and optimised for that.  Mixing their functions affects their usability and clarity.



Valid points, however this should be a choice. Not something mandated by the lack of a feature.
2015/09/01 11:26:46
KPerry
I'll argue with that (politely!): trying to cater for every desire can - note I say can! - lead to a bad implementation or too much complexity or bad UI.  Sometimes one and only way of doing something is a good thing.
2015/09/01 11:26:52
xbitz
will we able to put clips with different fx chains into the aux tracks (with clip based automation curves) or it remains a dream ?  (so do we able to change the audio routing on the aux tracks, from clips(fx) > fx rack > track out to fx rack > clip(fx) > track out ) different fxs on different now time positions would be nice 

hope it makes sense ...
2015/09/01 12:04:01
streckfus
KPerry
I'll argue with that (politely!): trying to cater for every desire can - note I say can! - lead to a bad implementation or too much complexity or bad UI.  Sometimes one and only way of doing something is a good thing.



I'll counter that (politely!): I do agree that it's a slippery slope when trying to cater to everyone's desires, and if CW was planning on changing the track/bus UI entirely I agree that it could introduce some unexpected behavior or complicate the workflow everyone is used to.  However, as I understand it, this new patchpoint feature is more of an "under the hood" type feature that doesn't affect any of the existing functionality on the surface, it just allows for more routing flexibility for those who choose to use the feature.  Those who have no use for track-to-track routing, recording synths, printing a bus to a new track etc. won't need to do anything differently because the track/bus setup will remain as is.  If there is added complexity, it'll only be for the users who wish to use this feature, and I for one would be okay with wrapping my head around a new UI for signal routing or dealing with some usability bugs/issues because in the end it would be worth it.
 
I just think it's awesome that Cakewalk is working on a flexible feature like this, but appears to be doing it in such a way that it will have zero impact on the existing workflows for those who have no desire to use it.
2015/09/01 12:13:04
Zargg
Very well written, streckfus. I agree, and hope it is "under the hood / bonnet" fixes that allows this.
All the best.
2015/09/01 12:21:10
KPerry
I think we're in agreement on that piece: the current track-to-track/synth recording features don't look like they're going to mess with the UI piece and look independent of bus/track merging!
2015/09/01 16:07:22
Dave Modisette
Noel Borthwick [Cakewalk]
No GUI required today - patch points are created from the track input/outputs and show up in the menus.
Although in the future we could do some fancy routing matrix view.


I would hope that you wouldn't use manpower for a "cute" GUI.  I love the idea of patchpoints though.
2015/09/02 11:20:49
streckfus
Dave Modisette
 
I would hope that you wouldn't use manpower for a "cute" GUI.  I love the idea of patchpoints though.




You'd originally submitted a feature request for CW to rethink the current track/bus setup, correct?  Kinda neat to see this patchpoint feature in works, eh? :)
2015/09/02 11:39:22
Makzimia
Very impressive. Nice work going on yet again. 
2015/09/02 15:07:41
Kylotan
KPerry
I also think there is a definite advantage in thinking about busses and folders differently: folders are for organisational purposes and should be focused on and optimised for that; busses are for mixing and should be focused on and optimised for that.  Mixing their functions affects their usability and clarity.



And yet at the moment, buses themselves are used for 2 different purposes - (a) for grouping submixes, and (b) for send/returns. And they're mixed in together. For me, it's annoying that if I just want to treat 2 tracks as 1, that has to happen down in the bus pane instead of where the actual audio or MIDI events are in the track pane.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account