mike@TrackTeam Audio wrote:wow! that looks pretty cool. unfortunately, i cant offer any insight as to the behavior your getting. some of the issues seem a bit weird though especially;
PROBLEM : when moving the start point of the clip, the playing position moves too
I may have not been clear on that point, but in fact it's quite simple, not even linked to the API, and you can try it :
- Launch a non looping audio clip in session view, and look at the clip view
- Move the start point of the clip 4 bars to the right
- Normally, the playing position will make a jump of 4 bars to the right too
This behaviour is logic, because live represents the playing position as " playing position is 17 bars from the start of the clip "
, so if you move the start of the clip, the playing position will be changed too.
But It would really be great if live represented the playing position as " playing position is 17 bars from the 1. 1. 1 of the clip "
which is really different. Because in that case, moving the start point would not make the playing position move, and I would not have any problem !
mike@TrackTeam Audio wrote:i would also recommend checking out live clip chopper by myralfur. to get decently timed jumps to different regions of clips you have to load the clip into ram. not a big deal for using a few short loops, but for full track in a dj stylee set, might not be efficient. hope this helps,
I have already tried this plugin, and i presents the same problems, even if clip are loaded on ram, as it uses the same functions.
If you want to be sure, just try that :
- Create a new live set
- Put an audio track with the live clip chopper
- Put some audio clips in session view
- Set recording on, so as you can view the result in arrangement view
- Launch a few clips and make some jump inside clips with live clip chopper
- Open the arrangement view
What you will see is the following :
- Launching another clip than the playing clip is OK, as in my device
- Moving the playing position of the clip is not precise, the jump NEVER happens EXACTLY on a beat
mike@TrackTeam Audio wrote:not tying to offend but maybe there are mistakes in the implementation? if your interested i could take a whack at the patch? you could pm me if your interested. Or maybe even contact the abe or cyclings and see if they can offer a solution or tell you that it just wont work, for instance with the metro being 160 ticks off, maybe thats just a limitation of the api.
Yes, in fact, I'm pretty sure that this is a limitation of the API, because the API is not at all real time. That would be ok if there where some escape solution, but for the moment I can't see one, that's why I'm begging for help.
BTW, Here are two a links to development versions, which use two radically different ways to make the jump using the "Goto" button :
This old one
uses a metro to trigger a move_playing_pos using the M4L API.
This last version
which I just made to try a new idea :
The idea is in the js, here it is :
Code: Select all
// this is the position were the user wants to jump to
// this is the current start pos of the clip
var startPos = playingClipAPI.get("loop_start");
// this is the current playing pos of the clip
var currPos = playingClipAPI.get("playing_position");
// I move the start position so as when i will call "fire", the playback will start at the desired point
// I call move_playing_pos in order to compensate for the jump of the playing pos due to the setting of the start point, just above.
// I call "fire" so that the jump will be effective on next quantification, right on the beat.
And you know what ?? IT WORKS !!
Not, in fact it works SOMETIMES, because it seems that some other times, the "playingClipAPI.call("move_playing_pos",startPos-desiredPos);" line is not executed, or that the API calls are not executed is the right order, or something like that.
So it works about 50% of the time, perfectly randomly, but I think that I'm approaching the solution.