@Improv wrote:
@Zynewave wrote:
But still with the “Reverse” layout where a vsti is a sub folder of an effect?
The basic rule for the hierarchic engine: All MIDI, automation and audio signals flow from the bottom branches of the hierarchy tree up to the master track. No exceptions. Given that a synth needs to feed its output to effect plugins, the synth must be placed at a lower hierarchy level (subfolder to the effect). You can argue that you want the complete hierarchy swapped upside down, to get a top down visual presentation of the signal flow, but if you argue that the synth should be placed on a parent track to the effect, you have not understood the hierarchic signal flow.
And you did not understand the meaning of the smiley at the end of my reply. That is the ‘confused ‘ smiley, meaning that I was asking for confirmation. Sorry for breathing!!! 🙄
Sorry if my reply seemed offensive. Sometimes I read the 😕 smiley more as ‘disgruntled’ judged from the look of the smiley. I’ve spent a lot of time doing the redesign of the track layout inspired by yours and others valid arguments in the other topic. I guess I was hoping for a more supportive reply to my screenshot.
But still with the “Reverse” layout where a vsti is a sub folder of an effect?
The basic rule for the hierarchic engine: All MIDI, automation and audio signals flow from the bottom branches of the hierarchy tree up to the master track. No exceptions. Given that a synth needs to feed its output to effect plugins, the synth must be placed at a lower hierarchy level (subfolder to the effect). You can argue that you want the complete hierarchy swapped upside down, to get a top down visual presentation of the signal flow, but if you argue that the synth should be placed on a parent track to the effect, you have not understood the hierarchic signal flow.
I even wonder if the proposition that Frits have made to hide the sub tracks doesn’t give a similar result to folder tracks ?
At a later point I probably will implement this. Initially it will just hide the events, and leave any events on the group track unaltered.
I have started a new track layout topic. Please post comments to the track layout in that topic.
There are folder tracks and group tracks. I don’t know if they can be nested in the mixer. I’ll check tomorrow when I wake up.
So group and folder tracks are perhaps different things in Cubase. The scenario with group tracks I talked about earlier (where you have to select the group track as a destination on the individual channel mixer strips) was how I remembered group tracks from earlier Cubase versions. These group tracks were placed in a separate part of the mixer window, next to the bus channels. However they did not behave like folder tracks.
@acousmod wrote:
and if you can nest group tracks within group tracks, and if solo/muting the group track affects all tracks in the group, then yes.
I have Cubase SX 2.2. And the answer appears to be YES
Nesting group tracks ???
Are you sure ?
I’ve only seen group tracks on the same level, no group track inside a group track…Folder tracks LOOK very similar and are very useful because they can be nested, but it is only a way to group sequences in the timeline and has no impact on the connexions and effects. They remain a track by track assignment.
But I’m not a specialist of Steinberg’s softwares…
I googled for Cubase SX folder tracks, and it appears you can nest folder tracks. Solo/mute/record on the folder track will also toggle the tracks within the folder. But I could not find information that said the folder track appears in the mixer and has the same mixing possibilites as a normal track.
BTW-am I wrong or is what you describe above the same as Cubase SX’s group tracks? It sounds like it has the same function.
I think the last SX version I tried was SX1. No demo versions since. If Cubase group tracks appear in the mixer window with the usual fader and channel controls, and if you can nest group tracks within group tracks, and if solo/muting the group track affects all tracks in the group, then yes.
I’m interested in Fritz’s (or any users) arguements as to why the Podium ‘heirarchy’ is better
When I’m working on an arrangement, I prefer splitting it up in sections such as drums, vocals, synths for pop songs, or violins, violas, cellos, basses for classical stuff. When I’m mixing, I like to work on different levels, sometimes mixing the sections, and sometimes mixing sub-sections or individual tracks in a section. With the hierarchy approach I can do this. I audio enable the section group tracks, and I then have mixer controls for adjusting the levels between the sections. When I mix sections I also collapse the section groups, so that the tracks within the section are not getting in the way on the UI. With traditional sequencers you only have a flat hierarchy of tracks. These hosts tries to satisfy the need to use a single fader to mix several tracks with concepts such as group tracks. You have to select the group as a destination in your individual tracks. To me this feels like an afterthought, as an attempt to make a flat hierarchy behave in a hierarchic fashion. Some hosts also has ‘solo groups’ or whatever they call it, to allow several tracks to be soloed/muted with a single control. Again this is something you have to configure on the track, and to me is another weird construct to emulate hierarchy. In Podium this group behaviour is inherent in the hierarchy.
Furthermore, some of the controls you have on a typical flat-hierarchy channel strip are there to sort of compensate for something you really want to do in different stages. E.g. the pre/post fader switch. In Podium the meters are always showing the track output. If you want to meter the levels of an audio input before it is being mixed, you just put the input on a track lower in the hierarchy, and do the mixing on the parent track. The Podium track/mixer strip is very simple with few controls. You may need to create more of these tracks to achieve something you can do on a single track in other hosts, but this simplicity of the main building component appeals to me.
This was just a few thoughts that came to mind. There are of course a lot of reasons for the design of the hierarchic engine, which have evolved over many years. What I am pleased with is that it is a very simple, efficient and flexible design. The job that remains is to make it more accessible in the UI.
Podium does have some sort of additional optimisation under the hood, that does not allow higher track counts to add to CPU load. Is this correct Frits?
If the track is audio enabled (i.e. it has a meter), then it will use CPU. But inserting effect plugins this way will not use more CPU than if you would add plugins to tracks in most other hosts.
I was a bit surprised initially that to add say a standard combo of a compressor and an EQ to a synth that you would have to wrap two tracks around the synth. Of course in Tracktion for instance only one track is needed. So for example a 20 or 30 tracks project in Tracktion or Cubase could very well end up having 60 – 90 tracks in Podium. This may actually be a bigger turn off for new users than understanding the hierarchical engine.
This was a problem for me initially, but not anymore.
It’s possible that Podium’s enigne is actually more CPU efficient than other hosts and therefore does not produce a heavier CPU load even with more tracks, don’t know though as I have not really tested this theory.
The idea I’m working on currently will allow to hide the track lanes for e.g. tracks that are only created to hold effect plugins. The word ‘track’ may be a bit misleading, as a track is basically just a mixing node in the hierarchy. The fact that you can assign timeline events to a track does not affect the mixer CPU efficiency.
I’m extremely open minded and merely await a convincing arguement that Podium is so much better.
We’ve talked alot about the hierarchical engine. I’d like to think there is more to Podium than that. Your arguments have been noted, and I’m currently looking at improving the track layout. Hopefully I have something to show for the next release.
@Improv wrote:
@duncanparsons wrote:
That sounds good..
…folks use that kind of tree structure everyday with Windows explorer, and have no trouble with that..Yes, but explorer goes from the general to the specific:
c:DocumentsBusinessInvoicesJanuarySmithandCo.doc ;
not SmithandCo./January/Invoices/Business/Documents/:cThe second path is how Podium looks to me right now, which seems counter productive.
We have opposite views on this. I see the C: root folder as the master track. With this view, the current track tree structure is similar to the file list you see in the Podium list window.
@Improv wrote:
@Zynewave wrote:
I don’t think this is practical. Collapsing group tracks would fold upwards, meaning the track you clicked to collapse moves upwards (away from your mouse pointer). Parameter tracks would be positioned above instrument tracks. etc.
Does this happen in existing sequencers/hosts like Cubase SX? I don’t think so. (Maybe, I don’t use groups in SX)
As I said earlier, in Podium the track folder hierarchy IS the signal flow. So if you want the group folders placed below the items within the group, to get a top down signal flow, then the tracks above would need to fold downwards. Quite the opposite of standard tree listbox navigation. If group folders in other hosts were used as signal path, then they too would flow bottom up.
Multiple mappings was a solution, because current “copy track” workaround eats track region space also. I vote for midi busses. What do you think?
I think MIDI over busses is the best solution for this.
You mean the right edge above the CPU indicator? Not right of the current Track inspector?
At the right edge of the timeline, before the vertical slider. A flow panel that can be dragged in size or hidden. If you take the hierarchy connection lines in the track header area, you just swap those horizontally so that the master will appear rightmost. Or rather; take the strip header area in the mixer, and rotate it 90 degrees to the right. The hierarchy levels would be wider, to hold the various dials and buttons.
Agreed. An option to hide those tracks would be very useful.
Here are some suggestions that may help…
I don’t think it has to be that customizable. I would add a ‘view’ menu button to the track inspector (similar to the view button in the mixer), with a ‘hide collapsed tracks’ option. When enabled, all tracks within collapsed group tracks would be hidden. Not just parameter tracks. The collapsing/unfolding of tracks would then behave just like e.g. browsing objects in the list boxes. You still have the ‘+’ button on the group track to indicate that there are tracks within that are hidden.
