More info on T2

[bastien]

Well I have soiled myself thanks to those latest new features - midi editor and mapping to be precise. Count me in for this upgrade!

[chico.co.uk]

Drum loops slicing and dicing would be also very nice. Just so I can keep them in tempo all the time. Pleaseeeeeee

maybe ACID/REX support

or is it too much?

If it's a must have, try ConcreteFX's Microdicer. It costs £21, and Jon, the developer has a forum here, and is very approachable

http://www.concretefx.com/MicroDicer.htm

[luka2807]

If it's a must have, try ConcreteFX's Microdicer. It costs £21, and Jon, the developer has a forum here, and is very approachable

well, it is not the same. It is plugin paradigm Vs host paradigm. I am hoping for total sliced loop integration within the host, so that I can move, copy, duplicate the loops without interfering the process flow with a plugin opening and dealing with a plugin that has 95% functionalities that I do not need.

Basicly, You drag the loop from explorer tree (or import it from the menu), click on it so that properties of loop are shown in lower part of the screen, slice it and finetune it so everythig is sliced as it should be, and loop is automaticly fit within the selected tempo. Then you can chage the tempo and your loop will always be in sync.

Frankly, I dont think this a too much of a prolem for Jules. I.e. I think that timestrecth engine (which sounds shity) is a much harder thing to program then basic drum loop slicing without any bells & whistles like filtering, effects and other sample manipulation things.

Beno, make my day

[warbug]

looks like the midi editor will be crap now

there is no reason to have the velocity at the bottom like that, should have just left it as it was....

[valley]

Frankly, I dont think this a too much of a prolem for Jules. I.e. I think that timestrecth engine (which sounds shity) is a much harder thing to program then basic drum loop slicing without any bells & whistles like filtering, effects and other sample manipulation things.

You'd be surprised. Peak slicing, and the necessary management of slice points is rather complex to code. In many ways pitch shifting is trivial in comparison - get (license) a good pitch shifting algorithm and throw your audio at it.

[nuffink]

Beno,

Does the midi editor support relative snap?

[valley]

looks like the midi editor will be crap now

there is no reason to have the velocity at the bottom like that, should have just left it as it was....

what's wrong with having it at the bottom. Assuming the 'v' toggle key still works it is no harder to use than the current form, but is a little more flexible.

[headquest]

looks like the midi editor will be crap now

there is no reason to have the velocity at the bottom like that, should have just left it as it was....

what's wrong with having it at the bottom. Assuming the 'v' toggle key still works it is no harder to use than the current form, but is a little more flexible.

I much prefer the look of the new editor, and I'm very pleased that the velocity lane is shown. I'm certain this will help my workflow as I've found this approach useful in other hosts that I have tried and liked in the past.

[TheWall]

luka, if that's the only things you want, that's pretty much what a slicer plugin is for and does. Microdicer is probably the best atm. And it also worths to ponder the idea that one day you might want to switch your host - I learned the lesson due to switching from my previous host to T.

Having said that, yes, I believe an integrated slicer should be a better solution than a 3rd party one. Also, in the early days Jules had said he would add a slicer sooner or later. So if T2 comes with a slicer, I wouldn't be surprised.

[chico.co.uk]

looks like the midi editor will be crap now

there is no reason to have the velocity at the bottom like that, should have just left it as it was....

what's wrong with having it at the bottom. Assuming the 'v' toggle key still works it is no harder to use than the current form, but is a little more flexible.

Gotta admit, it NOT being at the bottom was always something that threw me a bit, I could never properly remember what notes I was editting the velocity on. I much prefer the idea of the new look

Luka, i was just pointing out there's a low cost way to do beat slicing (without too many bells and whistles) that already works in T1. That has drag and drop and rex support. If you don't like it, fair enough.

[luka2807]

You'd be surprised. Peak slicing, and the necessary management of slice points is rather complex to code. In many ways pitch shifting is trivial in comparison - get (license) a good pitch shifting algorithm and throw your audio at it.

Well, thats not a fair comparison. You can also get an algorithm for slicing if thats your point. But, at the end I am 100% sure that slicing (basicly a beat detection) is much simpler then time strecthing. You can take a look and you will see that there is very few good sounding pitchshifters/timestrechers but almost all slicers/dicers work close to perfect. Of course, timestreching can be used on all kinds of loops, slicing otoh is used on drum loops only but isnt that the case in 95%

regards from croatia

[cbit]

You can also get an algorithm for slicing if thats your point

true that.

[valley]

Well, thats not a fair comparison. You can also get an algorithm for slicing if thats your point

no you can't.

a picth shifter is just a plugin - the relevant code for getting audio to and from the shifter exists in Tracktion, as it would any vst capable sequencer. An off the shelf shift algorith could be bolted into a sequencer in a matter of hours.

splicing a loop only solves half of the problem though. There still needs to be a way for clips to actually do something useful with the spliced audio. This isn't bolting something on, it's fundamentally changing some aspects of how clips work, IE.. not a few hours work.

But, at the end I am 100% sure that slicing (basicly a beat detection) is much simpler then time strecthing.

And I'm 100% sure you are wrong...

You can take a look and you will see that there is very few good sounding pitchshifters/timestrechers but almost all slicers/dicers work close to perfect

That has no bearing on the discussion. Pitch shifting is a mathematical compromise that could be the subject of years of research. That it doesn't always sound great doesn't mean it is hard to implement, just that it is hard to design the algorithms. If you have a pre-designed algoritrhm (which most sequncers do) then you have next to no work to do. Splicers on the other hand present exactly the opposite problem : the theory is easy, but the implemntation is a crap load of drudge work.

[cbit]

a picth shifter is just a plugin

but tracktion's time stretch engine isnt is it?

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).

edit

Then you can chage the tempo and your loop will always be in sync.

my bad. i missed this bit. that does sound tricky.

[IIRs]

splicing a loop only solves half of the problem though. There still needs to be a way for clips to actually do something useful with the spliced audio. This isn't bolting something on, it's fundamentally changing some aspects of how clips work, IE.. not a few hours work.

Are you sure about that? Surely, once the beat detection has split one clip into several, they just act like normal Tracktion clips..?

Basically it would just be an automatic "/" operation.. or have I missed something?