More info on T2

[valley]

a picth shifter is just a plugin

but tracktion's time stretch engine isnt is it?

I'd be surprised if it was anything more than a wrapper around the same code that pitch shift filter uses. If I was writing that code and I was being constructively lazy I'd just set the time stretch up as though it was a permanent filter that didn't show on the clip. The settings for the timestretch would just be auto filled in by the clip.

There still needs to be a way for clips to actually do something useful with the spliced audio.

what else needs to be done? (maybe i'm only imagining half of what's being discussed).

Look at it like this: Tracktion has no support for merged audio clips, and unless this feature is a T2 feature, I'd guess that given the amount of times taht feature has been asked for, it is not trivial for Jules to implement.

That leads me to believe that audio clips are nothing more than pointers to a section of a wav file (which would be a good way of implementing them). The problem here though is that to implement sliced audio requires the clip to be something else entirely, it requires it to understand break points, and merged audio. You can't just play the clip by sticking an index at the sample start position, and incrementing it until you hit teh end position.

For splicing and clip merging to work the clip[1] has to support a whole event list of individual audio files, and at each step of the way Tracktion has to look at which event within that clip should be playing.

The upshot is that Tracktion needs to be altered such that clips can contain clips, almost like a microcosm of a track, and hwn the tempo is changed these clips need to all realign themselves intelligently.

None of this is hard, it's could just be a lot of drudge work, like I said...

[1]Probably it would make sense to create a "super" clip that contains a bunch of standard clips, rather than changing the action of the audio clip itself, but that's a different discussion entirely.

[chico.co.uk]

a picth shifter is just a plugin

but tracktion's time stretch engine isnt is it?

Isn't it? What makes you say that? I remember a thread when someone pointed out a different time stretch algo for sale on the net to Jules, and jules thanked them and said he'd look into it. I doubt he reinvented the wheel when people have already done the research and worked out algos ...

There still needs to be a way for clips to actually do something useful with the spliced audio.

what else needs to be done? (maybe i'm only imagining half of what's being discussed).

Speaking as only a very very amateur hobby programmer with no c++ experience, you'd have to implement dragging and dropping slices from the bit at the bottom to the edit window and back, a way for them to be locked to tempo when in the edit (which nowt else audio in tracktion currently does), being able to tweak the slice positions after it autoslices, for when the algo gets it wrong, being able to rearrange slices in the bit at the bottom etc etc

The peak detection could be an algo, but the rest is work you'd have to do. I dunno how difficult it is, but it's more than just putting a timestrech algo in, I'd have thought ...

Eh ... what's the bit at the bottom of the tracktion interface called?

[chico.co.uk]

I knew i should have waited till a real programmer answered ...

what valley said

[cbit]

The problem here though is that to implement sliced audio requires the clip to be something else entirely, it requires it to understand break points, and merged audio.

this is the bit where i get lost i think. I don't understand why merging would be necessary.. (i'm thinking of a very 'simple' transient detecting auto slice macro.. not tempo synched etc).

[haydxn]

well i agree that it would definitely be more effort to make an integrated slicer than a pitchshifter/timestretch. of course a ps/ts algorithm needs to be of a high quality to be 'good', but it's only an effect after all, which simply gets applied to a section of audio.

integrating slicing requires more.

for example: take your 'automatic / function' idea; that's a fine one, and i'm sure it'd be neat and not too tricky, but imagine it was implemented in current T1 mode. if a clip had a RIGHT-CLICK->BeatSlice clip function. yeah, that'd be super, but it would require the clip to be a perfect loop for the current tempo (and fit perfectly into a bar) to be of any use.
Sure, that would now mean that changing the tempo would slide the positions of all the parts..

but what if you want to move the loop as a whole? you'd have to select them all and copy them.. which isn't really a decent solution, so you'd need a new clip type for 'sliced loops' to be able to contain them as a single loopable block..

so now thats another piece to consider and implement. and then theres the fact that most slicers have extra control over the slice positions, looped slices etc.., there is a heck of a lot more going on than a single algorithm effect being applied to an audio stream/block. it may not be as CPU intensive or as scientifically specialist as a timestretching/pitchshifting algorithm, but it's not as if its a no-brainer to integrate it into a host.

crucially, it requires a refined interface in order to be of use, especially in a program as sleek as Tracktion. at the end of the day, ps/ts effects only require a few parameters.

[IIRs]

[1]Probably it would make sense to create a "super" clip that contains a bunch of standard clips, rather than changing the action of the audio clip itself, but that's a different discussion entirely.

I sort of assumed that that would happen.. maybe cos I asked for it so often.

The way I see it, all the beat slicer needs to do is split the clip. From that point on, they're just normal clips (if you chop up a loop manually, then change the tempo, the loop tempo will follow) the only problem being one of conveniently dealing with the loop as a whole.. but so many people have asked for a way to non-destructively link audio clips, I sort of assumed that would be included anyway..

[cbit]

RIGHT-CLICK->BeatSlice clip function. yeah, that'd be super, but it would require the clip to be a perfect loop for the current tempo (and fit perfectly into a bar) to be of any use.

.. to you maybe everyone works differently.

[chico.co.uk]

The way I see it, all the beat slicer needs to do is split the clip. From that point on, they're just normal clips (if you chop up a loop manually, then change the tempo, the loop tempo will follow)

Hey, you've got a point ... off the top of my head i didn't think that worked, so i opened a project, imported a 4 bar loop and sliced it at bar 2 and bar 3, and then changed tempo. The slices moved to the new bar 2 and bar 3

I didn't actually realise that happened. Shows you how much beat slicing i do except when mucking around

[haydxn]

well, i mean to use it as a proper 'loop' tool; to import a loop and then slice it to the tempo of the track, would require it to be at the current tempo (otherwise the current positions of the slices wouldn't line up with the correct mid-bar divisions, and thus wouldn't "stretch" with the track in the conventional way)

i don't use loops. i hardly even use instruments now! that ironing session opened crazy worlds of sound for my confused hobbycraft!

[IIRs]

well, i mean to use it as a proper 'loop' tool; to import a loop and then slice it to the tempo of the track, would require it to be at the current tempo

Tracktion already has tools to match the BPM of a loop.. maybe not totally automatically, but then what does? Even Acid needs its files to be "Acidized" first..

[haydxn]

yeah i know. it's just another step tho, which is my point on how it's not just 'an effect' like pitchshifting or timestretching. it requires additional interface integration, and thoughtful UI design to be of proper use. that guarantees that it's not going to be as simple to integrate as a PS/TS

[Jeremy_NSL]

Piano roll improvements, yay! I'd still like more details on the changes, but what is listed sounds pretty good. Hopefully the need to switch between pencil, eraser, and selection tools is minimized somehow. And the wonkiness of resizing/moving is taken care of.

As for beatslicing, I'd personally prefer if it was integrated into the sampler, ala Orion. After slicing, the midi data is automatically imported to a clip on the same track.

I don't really need beatslicing, but I wonder if the sampler has seen any improvements? I seem to remember Jules starting a thread asking for ideas, and for sure sf2 support was mentioned... Sort of irrelevant with sfz around now - except if Ts sampler does more on the editing/modulation side.

[valley]

I sort of assumed that that would happen.. maybe cos I asked for it so often.

I dunno. I've asked for it a lot too. I hope it does.

The way I see it, all the beat slicer needs to do is split the clip. From that point on, they're just normal clips (if you chop up a loop manually, then change the tempo, the loop tempo will follow) the only problem being one of conveniently dealing with the loop as a whole.. but so many people have asked for a way to non-destructively link audio clips, I sort of assumed that would be included anyway..

Yeah, I saw your post after my first repsonse to cbit, but didn't have time to reply.

You certainly *could* implement a poor man's slicer in teh way you describe, and frankly I hadn't really even thought of it. My feeling though is that most people would use such a thing for loops, and copying and pasting loops that are comprised of 20 or so minute clips, would become a mjor source of complaints on this forum.

I dunno if you have worked a lot with audio clips that are shorter than one beat in size, but I find it gets very fiddly. I think for an implementation to be useful grouped clips would be essential.

Of course this discussion is academic since the feature list is at this point unknown, and only Mackie/Jules has any say on if, when, and how such a feature would be implented.

[mcnelson]

I'm still sold just on the MIDI stuff - looks hellagood now! Looking forward to playing with this.

[IIRs]

Of course this discussion is academic

[digression] Does anyone else find it amusing that in this context "academic" means "pointless"? [/digression]