Originally Posted by
Phi
I am talking about a mpc style realtime slicer, which might possibly solve your problem
On button press "slice" oneshot samples, drop them into the sample decks and do the re-arranging via automated sample playback. If you get your slices quickly enough this shouldn't be hard right?
it's an interesting idea using the sample decks - but ofc u need to use all 8 of them to do it this way. still be a neat trick if it works tho.
every 8 beats you'll need to reload all 8 samples - or u intent continually loading them while other samples are being played? not sure that'd work as you won't have beats 1-8 for the current 8 beats loaded? or is this a one shot deal? i.e: click to load all samples into the 8 sample decks? once they're loaded the only automation needed will be to trigger them consecutively *but* not if the user has pressed a button to jump to a different one.
doing it this way would be extremely simple using some midimasher code ofc - i wanted to slice the current track continually as it's playing - but your idea of just loading into sample decks is pretty cool too...
i've added some timing code into dump.exe and here's a simulation of what i do to get to beat #7 using this debug config:
Code:
open_midi_device("traktor", "traktor", "", "V:fake");
print "waiting..."
msleep(5000)
print "sending"
send("traktor", "jump_to_active_cue_point_a", ON)
send("traktor", "beatjump_+4_a", ON, 0, 1)
send("traktor", "beatjump_+4_a", OFF, 0, 2)
send("traktor", "beatjump_+2_a", ON, 0, 3)
send("traktor", "beatjump_+2_a", OFF, 0, 4)
send("traktor", "beatjump_+1_a", ON, 0, 5)
the 5 second sleep is so i have time to run debug.exe and connect to the newly created virtual midi port "fake". that produces this output:
Code:
log filename (press enter for none):
1: Midi Through:0
2: LPD8:0
3: fake:0
choose a device: 3
q to quit
CC 51 127 0xb5 0x33 0x7f chan=6 elapsed=3330.3
CC 21 127 0xb1 0x15 0x7f chan=2 elapsed=1.2
CC 21 0 0xb1 0x15 0x0 chan=2 elapsed=1.1
CC 20 127 0xb1 0x14 0x7f chan=2 elapsed=1.1
CC 20 0 0xb1 0x14 0x0 chan=2 elapsed=1.1
CC 19 127 0xb1 0x13 0x7f chan=2 elapsed=1.1
must have taken me 2 seconds to fire up dump.exe hence the 3 seconds delay before the first event coming in.
u can see it's not bang on 1ms between events but pretty damn close
i ran that on linux - u can see how easy virtual midi ports are on mac and linux. loopMIDI does have a dll available for creating ports but i haven't managed to get access to it's api yet. if i can that would be a solution for windows - or maybe sometime i'll have a go at writing my own virtual midi port driver and just embed it into midimasher (for windows only)
u can also see from that with coding in midimasher actually rarely needs midi details - it's all done via event names. u *can* also send midi if wanted ofc
edit: so the timing info i added to dump.exe seems to work ok - will be in the next midimasher release or i can upload a copy sooner if u want it
Bookmarks