Tracktion 3 preview

[koolkeys]

Alas Greg, you forget that they ARE at least putting in "Automation follows clips", so at least it's there in some form! And of course, Beno already said that they will improve it later.

Brent

[koolkeys]

By the way, you obviously can't expect EVERYONE to be happy. Only EXT2 will do that(j/k, although it's the most likely to do that)! There will be some users lost with the release, but I would guess there will be even more users gained.

I think T3 is going to be good for Tracktion. And for those waiting for a feature that hasn't been announced, just remember that:

1. The feature set hasn't been fully released yet.
2. They have obviously listened to requests, and will continue to do so.

I'm happy about it at least.

Brent

[Lunch Money]

Alas Greg, you forget that they ARE at least putting in "Automation follows clips", so at least it's there in some form! And of course, Beno already said that they will improve it later.

Not forgetting at all. But since that's public knowledge and he's still after per-clip, my question stands-- how should it work?

Actually... now I'm curious about how the Automation follows clips works for overlapping clips... averages the curve? I don't like that compromise, but I can't imagine what else it would be.

As for eXT... I've owned it for a long time and followed it for even longer. I wish Jorgen the best of luck with everything, and I will follow eXT as it grows and becomes a world-dominating force of good and justice for the world. I will pay for an upgrade when he finally decides to charge for one. But it's still broken in many ways, and I think people are sometimes afraid to call attention to that fact for fear of looking stupid. I, for one, am not afraid of looking stupid. It'll be interesting to see it in its next incarnation, in any event.

Greg

[headquest]

The reasons have already been discussed to death, even in this thread! There haven't ever been any "specifics," but the short version is: it turned out to be waaaaaayyyy more complicated to fix than anybody could have anticipated...

What Beno has stated (which I'm sure he worded carefully ) seems to directly contradict this. The fact is that they have apparently not even assessed whether it will be complicated or not to fix...

We haven't yet tried to fix it...

Over the last year or two I have often seen several people assert that fixing this issue requires a full audio engine rewrite. I assumed that was something Beno had previously confirmed, as it has been repeatedly stated with real conviction. It now seems that those claims were no more than speculative BS - Mackie have not yet looked at it:

At some time before release, we will look at the first note bug...

...There are no guarantees on if it can/will be fixed in the allotted time...

It seems clear that Mackie don't presently know what is involved in fixing it or how long it will take. As you say, they will obviously WANT to fix it. The related rewire and MIDI note-dropping issues have driven some of us nuts for several years... but clearly Mackie have had other priorities (i.e. income-generating feature additions) which to them were more important than the user feedback about this long-standing problem. It's good news that - at last - they ARE going to look into it though... let's keep our fingers crossed!

In spite of this, I still do remain positive about T3 - there are clearly many fantastic and much-requested additions to the program. But what matters most in the end is whether the program works smoothly... Beno's comments, and the low priority apparently given to bug fixing, have come as a real suprise to me at this point.

[haydxn]

Alas Greg, you forget that they ARE at least putting in "Automation follows clips", so at least it's there in some form! And of course, Beno already said that they will improve it later.

Not forgetting at all. But since that's public knowledge and he's still after per-clip, my question stands-- how should it work?

Actually... now I'm curious about how the Automation follows clips works for overlapping clips... averages the curve? I don't like that compromise, but I can't imagine what else it would be.

Greg

Well it's undeniably a useful feature, and as you say, it's tricky to figure out the logistics of such a system. but you worry about when clips overlap, and to that i say - don't make them overlap! what would you gain from overlapping them? why would you ever want to? the only reason they would overlap is if you dumped one on top of another by accident, and it would be sensible to just smooth between them, perhaps a transition from the value just before the overlap to the value just after the overlap. i hear you that it's a situation that would need a solution, but it's not a situation that would need a super complex solution, as it is - ultimately- a situtation that shouldn't actually be a real problem.

now, of course, i overlap clips heavily. it's a fundamental part of the way i work. but then if i was doing that, i wouldn't bother using automation on a per-clip basis, because i would want to control how it goes over the whole thing. i imagine you would probably do the same. i think the automation-follows-clips feature would probably be enough of a solution for that anyway (should i wish to have a repeating automation path for a few bars) providing copy/paste works fine.

i just think you're making a bigger problem out of it than there needs to be (which is something that is easily done in programming!)

[headquest]

Well it's undeniably a useful feature, and as you say, it's tricky to figure out the logistics of such a system. but you worry about when clips overlap, and to that i say - don't make them overlap! what would you gain from overlapping them? why would you ever want to? the only reason they would overlap is if you dumped one on top of another by accident, and it would be sensible to just smooth between them, perhaps a transition from the value just before the overlap to the value just after the overlap. i hear you that it's a situation that would need a solution, but it's not a situation that would need a super complex solution, as it is - ultimately- a situtation that shouldn't actually be a real problem.

now, of course, i overlap clips heavily. it's a fundamental part of the way i work. but then if i was doing that, i wouldn't bother using automation on a per-clip basis, because i would want to control how it goes over the whole thing. i imagine you would probably do the same. i think the automation-follows-clips feature would probably be enough of a solution for that anyway (should i wish to have a repeating automation path for a few bars) providing copy/paste works fine.

I agree. I was thinking about this clip-based automation thing though and I'm interested in the way Sonar 5 dealt with it. Basically, each clip has its own actual effects bin, seperate from the mixer paradigm. Move the clip and the effects bin/effects settings/automation/etc all move with it. It would be a bit mind-blowing to wonder if/how this could work with instrument plugins as well as effects, but I guess the whole mixer paradigm and track-based mentality would falter completely at that point?

Enter Tracktion - without that mixer paradigm in the first place! I wonder whether it would work well to have a clip synth and effects bin where filters can be dragged? If so, the possiblities would be pretty wild, no? But maybe this would break the Tracktion paradigm of being able to automate any parameter from any other track...?

It's already going to be interesting to see how the automation works in T3 and how it will continue to evolve... specifically, will it have become more traditional, or might it have become even more radical than before?

[pHz]

Over the last year or two I have often seen several people assert that fixing this issue requires a full audio engine rewrite. I assumed that was something Beno had previously confirmed, as it has been repeatedly stated with real conviction. It now seems that those claims were no more than speculative BS - Mackie have not yet looked at it

the suggestion that fixing it would require a low level rewrite of the audio engine came from jules himself a LONG time ago ... i have no idea how accurate that assessment was (since the new mackie dev team already seem to have done other things jules thought would be VERY hard to implement) but when the apps original developer and creator of the core that T presumably still runs on states that there has to be something more than 'speculative BS' in it ... thats not to say that when the mackie team finally look at it they wont find a proper fix (or at least an interim one until the engine rewrite) in time for a T3.x release ...

slainte rob

[headquest]

the suggestion that fixing it would require a low level rewrite of the audio engine came from jules himself a LONG time ago ... i have no idea how accurate that assessment was (since the new mackie dev team already seem to have done other things jules thought would be VERY hard to implement) but when the apps original developer and creator of the core that T presumably still runs on states that there has to be something more than 'speculative BS' in it ... thats not to say that when the mackie team finally look at it they wont find a proper fix (or at least an interim one until the engine rewrite) in time for a T3.x release ...

Well, most of us engage in a little "speculative BS" from time to time ...Thanks for the clarification though - when I saw this attributed to Mackie it was obviously more a case of "chinese whispers" then "speculative BS"

But if Jules identified the cause/solution for the bug back in ?2003/4, surely he would have passed on that information/research to Mackie prior to T2? The question remains, why no priority or movement to deal with it during 2005/6?

Anyway, Beno confirmed they will now look at it, so let's all just hope they have a quick and complete success

[koolkeys]

I understand that many want the first note thingy fixed. However, think of it this way.

T3 is the first major release of Tracktion that is completely coded by someone other then Jules. Surely Tracktion isn't a small amount of code, and therefore I can imagine that any new developer would have to take time to get to know the program. I'm no programmer, but I would guess that this could take a while.

Would you want someone unfamiliar with the code to be rewriting the engine? I know I wouldn't.

Next, if Mackie spent what could be a large amount of time on the bug first, of which they are not aware of how hard it will be, then there wouldn't be all these other cool things added that people have desired for so long. Mackie is a company, and they are in it to make money. They have to have a product that keeps evolving, even if it means lingering problems. They have a TON of customers who never come in contact with the first note bug(myself included).

So while it may seem unreasonable to have waited this long, I don't think it really is. It's not like Mackie doesn't know about it. And if anyone thinks for a second that they don't WANT to fix it, they are crazy. Why wouldn't they? But in the grand scheme of things, where money keeps the doors open, some sacrifices must be made. That doesn't mean that important things are ignored. That just means that you may have to put things on the backburner while you continue to try and stay in the game.

What if they would have jumped into the rewrite, or whatever is required, and it takes alot longer then expected? Then we don't get features(like folder tracks) that help Tracktion to keep up with the competition.

I hope they fix the bug. And I am fully confident that they will. And also, just because Beno said that they haven't LOOKED at it, doesn't mean they haven't talked about it or put it into a timeframe that works with the release cycle. They just haven't jumped into the code yet to fix it, which is what I get from "we haven't looked at it".

But I would guess that it's on the HIGH priority list and will be fixed soon enough, possibly even before the release of T3. But who knows. Like Greg said, the coding team has already done things that Jules stated as much tougher to get done. So have confidence. I'm sure Mackie will please the masses soon enough.

Brent

[pHz]

Well, most of us engage in a little "speculative BS" from time to time ...Thanks for the clarification though - when I saw this attributed to Mackie it was obviously more a case of "chinese whispers" then "speculative BS"

for sure ...

slainte rob

[pdxindy]

pdxindy-- I'm curious about how you visualize clip-based automation working. I thought it was a no-brainer, too, until I tried to work the logistics through. Taking into account clips that might overlap (and yet feed the same softsynth), moving clips to other tracks that don't contain the same plug-in, etc., etc., I ended up having a very difficult time working up a model for a working per-clip automation idea. It's one of those things easier said than done, and I for one can't figure out how to do it within T. I'm sure there's a way, but I haven't seen anyone actually put the idea forward. Most people are content just to ask for it. For example, what would be the expected behaviour of an automation curve when two clips overlap?

Greg

I don't know how to do it in T, except leave it up to the user not to overlap and use clip based automation at the same time.

Different people have different uses/needs/working methods. I would myself prefer to have clip-based automation rather than overlapping clips if I had to choose. Maybe the great majority of T users would want it opposite. I look at it primarily from a perspective of working with softsynths and midi clips.

The T3 upgrade looks solid and interesting for many people. I am curious if T3 will allow a softsynth to be recorded directly to audio. My interest is basically academic because Live works very well for me. Even though I ended up frustrated by certain limitations, I still have a soft spot for Tracktion, especially because it was the host that led me away from Cubase hell and validated my feeling that a host need not be so complicated but could be more fluid and fun.

The combo clips look really nice, and I will be jealous of folder tracks too.

btw, the loop library looks quite similar to the one that ships with Apples Soundtrack Pro. (an underated piece of software) I wonder if they licensed it from Apple? (or both licensed it from someone else?)

[Lunch Money]

headquest-- When Beno said "it hasn't been looked at," I think it's fair to say, "it hasn't been looked at (ie. worked on... which is an idiomatically different thing)for this forthcoming release," and not jump right to "it hasn't been looked at at all, EVER,"

Re: clip-based automation-->

I disagree that I'm overthinking it. Overthinking it is when you try to take a simple solution and apply an overly complex fix. What I'm referring to is not "over" thinking it, but simply thinking it. There are 2 basic situations above all others that need to be addressed, and those are the ones I mentioned. Anything else is just icing. Options for users on how to address these are just icing, but the basic functionality has to be in place or else it's just a pipe dream. Namely:

1. Overlapping clips. The two responses were both "Don't overlap." Well, that's not gonna happen. There will always be users overlapping clips. And when you're a brand new user, seeing the options "use track-based automation" or "use clip-based automation" aren't going to make any sense and they'll detract from the user experience. So, there simply HAS to be a way of taking it into account.

The problem? You automate on parameter on 2 different clips. The sound of this particular plug-in's effect is a fundamental sonic piece of the puzzle which is absolutely integral to the clip, including the way in which it is automated. You overlap and want to cross-fade the two clips. But the automation is conflicting, and therefore that "overlapping area" of BOTH clips doesn't sound at all how you intended anymore.

You know and I know that you can't have a single parameter be in 2 places at once. But not all users will intuit that. They'll simply think, "weird, the end of my clip USED to go 'kerranngg' and now it goes 'bleep bloop'. The more counter-intuitive things people encounter, the less like Tracktion the application will continue to be.

2. Moving to a different track. OK, so you have 2 different clips, not even overlapping, on the same track. You decide you want to move one to another track for some reason. But it's still automating what.. the filter on the original track? But the clip doesn't even feed that track (and therefore doesn't feed that effect) anymore, so what good is that doing? It needs to automate a filter on its own track.

--

The ONLY way to make clip-based automation work in a non-broken way is to have each instance of the plug-in associate with each clip. As soon as a clip overlaps, an identical copy is made on each of the overlappers. Move to another track? No problem, Tracktion makes a copy of each of the plug-ins on the track so that there are 2 distinct sets that can be automated.

It's the only reasonable solution, and it's a CPU pig. I'd be willing to put up with it if it meant keeping everything in its proper place, and intuitive. But I suspect that people are going to go, "Oh, MAN... that's a LOT of CPU consumption."

Then there's the problem of moving clips that feed racks... clips that feed submixes...

It's only "overthinking" when it's a concept. When you're making it into reality it's just "thinking".

[pHz]

just thinking out loud greg so no pedantic shit OK ???

(heehee)

... in my mind 'full' clip automation in the future works like track automation (ie - any clip can hold automation for any filter parameter in the current edit) ...

... so clips that overlap (in time ... even on different tracks ??? ) that share an automated parameter (assuming clips share an automated plugin and no new CPU munching copies are created) ... ignore all nodes in the overlap section and 'draw' a line between the next available points before and after the overlap ... maybe even 'intelligently' treat the overlapping automation as a single entity to allow for a bezier curve transition ???

(beer in brain so might well be bollocks)

slainte rob

[Lunch Money]

It's a fair enough compromise, but the bottom line is that the only way of TRULY having clip-based automation is what I listed above. Loading duplicate instances for overlaps and track transfers.

The overlapping clips is one of the two problems. To be honest, I think the other is more important. Overlaps can be compromised. But what about moving clips to new tracks? If the curve just becomes "a curve without a home," and doesn't point to anything in particular, I guess you could manually assign it after moving it. Then the curve is simply treated as an independent entity, no longer tied to a particular filter.. it would have to appear in the list as "unassigned curves - formerly OnePingOnly" or something so that you could find it again and reassign it.

[GaryG]

Would you want someone unfamiliar with the code to be rewriting the engine? I know I wouldn't.

This guy talks a lot of sense, people should listen to him now and then...

I've been around long enough to remember Jules re-writing the audio engine the first time around (early 1.x sometime) and even he had plenty of problems... This first note bug sucks indeed but if it takes a while longer to fix properly then so be it. imho.

.g