FR: SNAPSHOTS!

[Lunch Money]

Exactly. Just different views of the same mix.

[willowhaus]

Question: If you take a snapshot, then add more tracks, what do you suppose would happen to those tracks when you recall said snapshot? Or, you delete one of the tracks that was there?

This is where it starts to get sticky, folks.

[haydxn]

well that could be easily implemented such that they simply appear on the bottom of the snapshot layouts at default height. when you change to a different snapshot view you just move it to somewhere else if you don't want it there. you'd have to change your snapshot anyway with additional tracks so it shouldn't be difficult at all.

[braj]

well that could be easily implemented such that they simply appear on the bottom of the snapshot layouts at default height. when you change to a different snapshot view you just move it to somewhere else if you don't want it there. you'd have to change your snapshot anyway with additional tracks so it shouldn't be difficult at all.

That's exactly what I was thinking.

[jens]

here's an idea: what if Jules would implement a conventional micer into Tracktion?

What do you all think? Is this idea something worth discussing about?

What are your OPonions?

[Lunch Money]

Begone, troll! Begone!!

<trows some chicken wings at Jens>

[braj]

I 'micer' would be great, get rid of the rats roaming the hallways. We usually call theme 'mousers' around here though. But maybe you call mice 'mices' I dunno.

[pHz]

heres an idea ... what if jorgen would remove the conventional mixers from energyXT ???

What do you all think ??? is this idea something worth discussing ???

What are your opinions?

slainte rob

[willowhaus]

well that could be easily implemented such that they simply appear on the bottom of the snapshot layouts at default height. when you change to a different snapshot view you just move it to somewhere else if you don't want it there. you'd have to change your snapshot anyway with additional tracks so it shouldn't be difficult at all.

But here's the thing: Assuming we index each track by its creation number for a moment, a snapshot would consist of a routine that fills (from a list/table of numbers) Track(a), size=x, Track(b), size=x, Track(c), size=x, Track(d), size=x (where, for example, a=4,b=7,c=13,d=14 in one snapshot, a=5,b=6,c=7,d=19 in another), plus error-checking so that if suddenly 7 disappeared the snapshot would omit it & display the remainder correctly. Now, we have to add to this a Track(remainder) that would display what's left, and again not hiccup on any tracks that are now gone, i.e. have it so that if we delete tracks 20-30 it would still display 31 & up, but not keep counting until infinity.

This is just a quick theoretical sketch - certainly doable, but not exactly trivial. The structure of such a routine would depend a lot on how things are coded up to now, and may or may not be easy to implement - and as you start to add more layers of functionality, the difficulty multiplies.

I'm not trying to talk anyone out of this, mind you - just pointing out that the idea that something is easy to implement may not be so easy for the one who has to do it. (Been there...if I had a dollar for every time someone said "just a couple lines of code" I'd be retired now. )

[IIRs]

I think he should remove the 'micers' as well.

whatever they are..

[pHz]

I 'micer' would be great, get rid of the rats roaming the hallways. We usually call theme 'mousers' around here though. But maybe you call mice 'mices' I dunno.

can we rewrite the rats so that theyre zoom-and-pannable though ???

i find the current rat view just too confining for my purposes ...

slainte rob

[haydxn]

i think you're looking at things in more complicated a light than needs be. i'm a programmer at heart too, and whilst i appreciate the distain for flippant "only a few lines of code" style comments, it doesn't strike me as something particularly complex. it does, of course, come down to how it is currently coded. but if the 'snapshots' simply held a list of the track order and height, then no i don't believe that it would be much of a complicated routine to handle the addition and removal of tracks. when a track is added it could simply have an entry added to each snapshot (not too taxing as there wouldn't be many snapshots anyway) with default height. if a track is deleted then it can also be removed from the snapshots at the same time.

but yes, it does come down to how it's coded at present.

[Lunch Money]

I'm not a 'real' coder, but I took 2 years of 'computer science' in high school. Back when year 1 was BASIC and year 2 was PASCAL. On top of that, I've done programming in an object-oriented language called LPC.

So, while I don't classify myself as a coder, I certainly understand the different types of arguments and checks needed, and as long as Tracktion operates the way I think it does (the edits are evidence that it does!), the snapshot function wouldn't be an enormous task. Of course, when I say it'd be 'small', I don't mean one hour. It'd still take more time than that.

[willowhaus]

Fair enough - it's really all academic until the Man Who Knows chimes in, anyway. I just read through the "Folders" thread, & saw that quickly become a myriad of options that could likely take several revisions to implement (with dubious results, in some cases).