Track classes, the pros and cons

[Argitoth]

Originally Posted by Lawrence

I for one would love a dedicated group bus class, and dedicated sub-out bus classes ... and those who don't could just not ever use them so, no user would ever be inconvenienced by it.

So the objection seems "personal", not practical.

Devs can only do so much. If they spend time implementing a feature that isn't useful, then they lose time on implementing a feature that IS useful. Track classes are not useful, period. Create a macro, create a track design, a menu item, a toolbar button, how is that any different than a track class? Another thing, you implement a track class and all of a sudden WALTER gets bloated, theme-ing gets bloated, more menu items are needed, etc.

ALL YOU HAVE TO DO to create track classes is configure the track and save it as a track preset. How is a track class any different? Maybe the devs can add a few features to make those presets more accessible and easier to integrate, but why in the world do we need track classes if a track preset can be designed in such a way that there is NO difference?

I made my own track classes. Midi, fx, audio, folder, etc. They each look very different from each other. The fx track is only visible in the mixer. You can already do stuff like this.

Another thing. REAPER IO panels could use some work. Implementing track classes would just make things worse in this department, when the time could have been spent improving already-implemented features. You'll be requesting features like "Make it easier to do buss IO!" after buss track classes are implemented. So why waste time on track classes?

My objection is very practical.

[Argitoth]

Originally Posted by Lawrence

It's the ... "One track class is always the best so don't touch it..." ... thing that leads to all of the various kinda workarounds to do the things dedicated track classes do easily.

Then request features that make those workarounds obsolete! Help improve what we already have!

[Lawrence]

Not that big a deal. No need to create a new thread just to debate that.

It's really ok if you can't personally see any advantages to optional dedicated track classes. It is. No need to debate all that (again). Starting a "pros and cons" thread and not listing any pros at all won't result in anything productive, just another unnecessary argument.

Thanks A.

It's not like they'd ever do it anyways so it's really not that important.

Track classes are not useful, period.

If you say so, I can accept your impression of that and move on.

[Argitoth]

I named it "pros and cons" for the sake others responding to the thread.


well I can't see the difference between two things that look identical.

...I guess that makes this thread useless since I am essentially arguing two ways of implementing the exact same thing...

Ok, so yes, I can see the advantage of track classes. I just can't see the advantage of track classes. So.. yeah. This thread is pointless.

[Lawrence]

Well, with all due respect, you weren't actually "asking" for a discussion, but more just "telling" everyone why I was "wrong" about that, so the thread was kinda doomed from the start.

It's like starting a thread asking which is the better car, Ford's or Chevy's, but then - before even allowing anyone to respond and give their thoughts - ... saying...

"There are no advantages to Ford's, period." End of "discussion".

Which kinda sounds like an argument just waiting for more participants. Why "discuss" a thing when it's fairly clear the person asking has already fully closed their mind about it?

[Argitoth]

You are correct, I don't care to discuss the issue. I just care to remove the discussion from the pre thread.

[Lawrence]

Originally Posted by Argitoth

You are correct, I don't care to discuss the issue.

I know, you wanted to 'debate' it, prove me 'wrong'. That's why I passed, not that important.

I think JCS is well aware of any potential pros and cons and they'll likely always do what they think is best for their baby no matter how we individually feel about all that... so... no biggie.

Thanks A.

[Lazarus]

The best of both worlds could be achieved if there were user definable track classes as part of a track's properties. Then track templates could be used more usefully in terms of the track class argument.

Blank tracks or templates with no class assigned could have all tracks visible to them as send targets and be exposed as send targets to all other tracks as they are just now.

The basic functionality could be that the tracks with assigned classes could have send availability and automatic addition/visibility of sends filtered or displayed on a class relationship basis.

eg.

Class 1 - Audio class
Class 2 - MIDI class
Class 3 - Instrument class
Class 4 - Buss class
Class 5 - FX class
etc...

Class 1 and 3 always has sends automatically added/visible to all class 5 tracks and has class 1 and 4 available as send targets.

Class 2 can't see 1, 4 or 5 and has no sends always visible.

etc. An override/show all icon where applicable would be needed to retain flexibility though. If there were MIDI and audio in/out checkboxes in track class properties then some extra filtering could go on in track inputs and the I/O window too.

As well as the routing thing, being able to assign more than one class to a track/template would allow for scripts to target tracks without having to put keywords/characters in the names.

[Amazed]

Any discussion here with the word Class in it is sure to go astray when a significant number of members here can code so I'm not sure what's meant.

Isn't this just about being able to give a track a type for which support could be provided. e.g. right align 'buss' tracks in the mixer?

If this is what's being discussed here, I remember some discussion on it a little while ago.

It doesn't sound a far stretch to initially provide an additional property e.g. 'type' on tracks for which support can be incrementally provided.