Fx automation and sample sequencing inside of Traktor (not simple but possible)

[Phi]

Thanks for the input

[zestoi]

No hassle, just import a .tsi and get a realtime beatslicer to auto-dump into the Remix decks.

still no way of doing a decent beatslicer afaik as u need to stack certain beatjumps together. i.e: u can dump +/- 1 or 2 or 4 but not 3.

if u want something to fire X times a beat surely the easiest thing to do is just feed the beatphase monitor back into a modifier (using virtual midi port again for feedback) without using the extra logic? tho u could ofc use an extra modifier to latch into the first to count the actual beats, so it can count up to 8 sets of 8 beats. no need for auto-repeat then.

[Phi]

...

[zestoi]

Exactly! That is what I'm calling a "gear" that built in automation by counting cycles. The engine concept is useful for manipulating the speed of an internal automation when no beat is present.

sure - but if there's no beat, ie: no track playing what's the point? i'd be impressed if u can come up with a solution to the beatjumps issue tho - that one is a total pain in the ass...

edit: i may well be missing something ofc - it happens a lot i do like what u said about using it as an LFO to control an effect - pretty cool...

btw i liked your idea for changing the colour of led's under a turnable to show which deck it's controlling from your post the other day i always assumed u could switch between timecode on/off for transport but don't own tsp so don't have those options mappable ofc.

[Phi]

...

[zestoi]

Well, I just use the idea to show that you can make Traktor step-sequence to an internal rhythm like it was a DAW. But, it's really a superfluous demonstration of flexability. However, it does illustrate how to turn ONE output into a cycle that produces SIXTEEN outputs...

be pretty cool to be able to sequence some remix deck stuff using ideas like this. ofc u probably can't as the b*astards at NI have seen in their ultimate wisdom to make them not midi mappable tho i guess we don't know for sure until we actually get hold of 2.5

Also, are you saying you can't beatjump in odd increments? I really think a beatslicer should be easy with multiple gears.

yup - and it sucks... my own midimasher slicer works pretty apart from the beatjumps that need multiple messages. u also can't send "jump to active cue" and "beatjump +1" at the same time, there needs to be some delay in betwee them else traktor decides for u that u didn't really mean to do that

same goes for stacking the controls just within traktor, i.e: you'd need to somehow first send the jump to active cue and some time later send the beatjump.

this behaviour of traktor choosing from what u have mapped to what it "thinks is best" and needing to add delays in is the reason there's no really solid slicer yet in traktor. mine works pretty well but not as good as in itch i'm sure. *sometimes* it won't jump to where u expected. it won't get out of sync since it everything is relative to the active cue point, but still a pain.

i have a lua table that maps from the beatjump needed and what messages need to be sent out like this:

["jump3"] = { "beatjump_+2_", "beatjump_+1_" }

then i have to send the jump to active cue, followed by this logic that steadily increases the delay for each subsequent message:

		for i,j in ipairs(traktor.beatjumps["jump"..jump]) do
			send("traktor", j .. deck, ON, 0, delay)
			delay = delay + 1
			send("traktor", j .. deck, OFF, 0, delay)
			delay = delay + 2
		end

the delay is in ms. i'm using midi clock to sync it but ofc u could use the beatphase. i've just found that midi clock seems a lot more stable. sometimes the beatphase seems to jump a bit.

sometime after i coded my first slicer implementation there was a blog article named "string theory for dj's" which used midipipe to add in the delays. same kind of idea as what i'm doing. i stole their idea of always jumping to the active cue followed by beatjump(s) tho as before i was just trying to jump relatively to the current location (+/-) but i couldn't ever be 100% sure what the current location was

[Phi]

I was aware of this flaw in Traktor, so what I'm talking about is being able to build your kind of slicer inside a .tsi for a controler and package it with it's own midi driver(virtual cable) and be able to SHIP a controller with a plug-n-play beatslicer.

[zestoi]

I was aware of this flaw in Traktor, so what I'm talking about is being able to build your kind of slicer inside a .tsi for a controler and package it with it's
own midi driver(virtual cable) and be able to SHIP a controller with a plug-n-play beatslicer.

u still have the exact same timing/stacked issues tho whether doing all the work within traktor or using an external script. there was a big thread about trying to work out this kind of behaviour in traktor quite a while ago and there's almost no differences between sending in multiple midi messages at the same time (the "same time" as far as traktor is converned anyway) or stacking the beatjumps and other stuff just within your tsi.

it is *possible* there's some kind of workarounds that can be done within the tsi to make it work - but we couldn't find any before. maybe if u used your latched modifiers to fire one beat jump *just* after the previous beat jump? the magic number seems to be about 2ms tho no matter how u do it for the delay.

i'd be very interested if u come up with any cunning solutions tho

[Phi]

I'm going to work on it tonight... Maybe have a .tsi by dawn, thanks for the help

[zestoi]

cool - i'll be interested in anything u come up with