thcilnnahoj's Forum Page

That’s a great explanation – thank you! I personally haven’t had the need for this kind of thing yet (I do have a lite version of Live but it gets no use!), but it looks quite handy. After watching the video however, I have no more ideas how it could possibly be improved any further… it’s pretty much perfect in both apps already for the kind of use you presented, isn’t it?

@H-man wrote:

@thcilnnahoj wrote:

Any kind of resizing (mixer, inspector, etc.) is extremely sluggish here when even just one embedded parameter is shown in the mixer.

I hate to stir things up but mine has become much better :-s and I have not updated drivers etc.

Correction to what I said: There doesn’t even have to be a single parameter visible – it’s enough that the “show editors” function is enabled. My guess is that it has to do with plug-ins that have long parameter lists, as it only seems to happen with those on my system. Here’s a test that worked for me: in an arrangement with just one or two tracks, load the free Voyager as the only plug-in, grab the mixer and drag it up and down as far as it goes. Try this with and without enabling embedded editors. CPU load is pretty much the same on my system for both, but the dragging is jerky with editors enabled.
As with all other things in Podium, the processing load on my graphics card (Radeon 3850) is rather low, so I doubt it has to do with that. :-k

Well, I’m sure there are much better ways yet to visualize the flow of a “span track”, as was suggested. It’s just the best I could think of at the time, but I’m certainly not the smartest UI designer in the world either! 🙂
It’s always nice to imagine cool ways of doing things, but the basic idea has to become a little more concrete at some point… So, does anyone have another good suggestion for a possible way of implementation?

I wouldn’t say no to the kind of feature Mike suggested in the opening post. As far as real modularity – which isn’t the topic though, I guess – is concerned, I stand by my comment that it’d better be kept (visually) separate from the normal tracks view.

Thanks for the screenshot, UncleAge! Though this particular setup with a multi-out plug-in I believe you could do in Podium easily, too.
What I can’t tell at all is how the rack(s) relate to normal tracks. Do you assign a complete rack to a track (are all the outputs downmixed then?), or can you assign separate “rack inputs/outputs” to tracks? :-k

Here’s my 2 Eurocents:

1. You asked for it! Just a simple mockup for a kind of reverse group track with a thinner group bar, a little like a shadow of the receiving tracks. It’s not unlike Frits’ “ghost play” idea. (With and without “input arrows” – arrows coming from below looks even worse! :lol:)

The biggest downside to this is that there’re as many limits to these specific kind of group/ghost tracks as there are newfound freedoms. Just for example, you can’t have a few tracks from your drum group routed to the same ghost track as tracks from your guitar and synthesizer groups.

2. The other idea I had is this: Like group or composite tracks, you could configure a track to function as a “relay track.” After you set it as such, this track doesn’t feed its output into the normal signal chain anymore, but instead is available as a source or input mapping to other tracks. This mapping remains only as long as the track acts as a relay track, and is removed when the track is deleted or reconfigured. Filtering MIDI notes would probably need two of these in sequence: one to generate, one to filter and a normal track to recieve – assuming you can’t put a MIDI plugin before a track’s input any other way.

With this you can route tracks freely from one end to another – just without cables. And that’s the downside, of course… There’s no visual indication of what flows where. Simply because of this, I think it’s just not a good idea to mix and match real modularity with a linear visual/signal flow like we have in Podium. Bar something like the zGrid, or the routing window in Reaper, which are totally separate from the ‘normal’ view of the tracks. This is after all probably the best way. But really… press TAB and get to see lots of cables dangling? Ohh no, thank you! 😛

For those of us who’ve never used Tracktion, would somebody mind explaining a bit about those racks?

That was quick! 😮 Here are some things that come to mind:

– In my opinion, the editors should start off minimized. I’d rather select the ones I want shown than scrolling through a gigantic list and having to close all of those I don’t need.

– Speaking of scrolling… Since every parameter listbox in the rack of course has its own scrollbar, there’s little space left to put the cursor while scrolling the rack itself. Using the mouse-wheel directly over scrollbars is awfully slow – could this be changed or is it some Windows default? It would also be good for, e.g., the horizontal scrollbar in the mixer if you don’t want to use shift all the time.

– It seems the scrollbar position is remembered individually for every track. I think I’d like it better if it was auto-scrolling to the focus track in the chain, like the mixer does.

– Maybe the max. parameter listbox size should be a little less tall. Here, the default rack size is too small to accommodate one complete listbox. If it would cut off 5 or 6 parameters earlier, you wouldn’t have to resize the rack to see and use the whole box and its scrollbar. (This is on a screen with 1024 px vertical resolution.)

– Oh, and add another yes, please to showing user-chosen parameters only (and all parameters if none are chosen)! I thought you already hinted at this during the 2.23 preview. 🙂

Alright, this time it’s related to 2.23, so I’ll put it here! 🙂

Tiny selection frame bug:
Select a track -> select an event on the timeline so the track becomes the inactive selection (you know what I mean…) -> switch to another profile -> select the track again. The selection frame color doesn’t update until you do some kind of refreshing action (scroll, etc.).