Implementing cues in M4L : needing some help...

Questions and discussion about building and using Max for Live devices
Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Implementing cues in M4L : needing some help...

Post by Crubier » Sat Jun 19, 2010 7:05 pm

I am developing an implementation of cues in M4L.
It allows the user to put cues on his tracks, go to cues, loop, watch remaining time to next cue etc etc...
I'm quite proud of the result but there are still some few problems preventing the "official" release...

For the moment, my problem is quite simple, but very, very annoying...

I can't find any way to move or set the playing position of a clip at a quantified time.

I have tried many many solutions, using MaxAPI or JavascriptAPI but none of theses works :
  • call move_playing_pos, triggered by a metro.
    (PROBLEM : The function call seems to be delayed a bit and happens about 160 ticks to late. If I put an offset to the metro, using @autostarttime, it doesnt work either... the move_playing_pos is executed 160 ticks too late or 160 ticks to early but never on time...)
  • set the start point of the clip at the specified time, and then, fire the clip.
    (PROBLEM : when moving the start point of the clip, the playing position moves too, so that a different part of the song is played when clip is fired but still not launched from its new position)
  • set looping ON for the clip, set loop_start at the desired cue point, and loop_end at the beat following the current playing position
    (PROBLEM : it works if you jump backward to a previous cue, but doesn't work for forward jump to next cues, since loop_start if necessarily befor loop_end)

An other solution could be creating a different clip with the start point at the desired time, but I don't know any possibility to copy a clip using M4L API.

Any idea would be really welcome since this implementation is really promising....

broc
Posts: 1148
Joined: Mon Jul 26, 2004 8:37 am

Re: Implementing cues in M4L : needing some help...

Post by broc » Mon Jun 21, 2010 9:01 am

Perhaps you should explain the overall concept a bit more.

Are you talking about clips in the arrangement?

If so, I wonder how to access them (other than via clip slots in the session).

Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Re: Implementing cues in M4L : needing some help...

Post by Crubier » Mon Jun 21, 2010 11:11 am

Ok, so here is a screenshot :
Image

The device is Called "Cues" on the screenshot.
A Cue is basically a structure containing a Position and a Name.

Cues are stored within Clip names, for example, imagine you have a clip which name is "SONGNAME".
Using the device, you add Cues to it, let's say "Start" at bar 0, "Break" at bar 32, "End" at bar 128.
The clip name will now be "SONGNAME Cues: 0:Start 32:Break 128:End"

If a clip is playing in the track, its cues are displayed in the device, else the Cues from the selected clip are displayed.

The device is basically a CellBlock plus some controls. The cellBlock contains a row for each Cue and three columns :
  • First Column is the Cue Position in the bbu format, if the edit mode is enabled, you can move the cue by editing the cell content
  • Second Column is the Cue "length", ie the duration before next Cue
  • Third Column is the Cue name, which you can edit if edit mode is enabled
  • Selected Cue is in yellow, and playing cue is in blue.
Just above the CellBlock, the text line displays :
  • Current Clip playing position, in BBU
  • Time remaining to next Cue in BBU
  • Clip name
The other controls are :
  • First, on top left, the Cue index selector, the number displayed is the Cue selected index (ie 1 here), you can move the index by different ways :
  • The second one is the Jump function, it allows the user to Jump back an forth of a quantized amount of time (2 bars in the example)
  • The third is the Goto function, which allows to set the playing point to the selected Cue (MY PROBLEM IS HERE), and launches the clip at the desired Cue if it is not playing
  • The fourth one is the loop control, which allows to set loop start at a selected cue, and loop end at another cue, and switch loopin on / off (not yet implemented)
  • The last one is the Edit button, which switches the edit mode on or off
All these controls can be midi mapped, and are available on Novation launchpad User2 mode, especially, the buttonMatrix allows the user to select Cues and goto them the same way as We can launch clip in Launchpad "session" mode

A javascript Max object is computing everything in the device.

broc
Posts: 1148
Joined: Mon Jul 26, 2004 8:37 am

Re: Implementing cues in M4L : needing some help...

Post by broc » Mon Jun 21, 2010 12:27 pm

Thanks for explaining. Seems quite an interesting device. I'll try to look at the timing problem.

ring (Simon Slowik)
Posts: 121
Joined: Fri Oct 30, 2009 3:35 pm

Re: Implementing cues in M4L : needing some help...

Post by ring (Simon Slowik) » Mon Jun 21, 2010 1:40 pm

I also found the playing position features of M4L not usefull as there are timing problems and some unconsistencies in the concept.
For what I've heard the MIDI Remote Script (written in Python) are updated in audio rate, so maybe that could be a way. Simply implement a method that turns on a clip and call that method from M4L.

cheers,
ring

Michael Hatsis
Posts: 1807
Joined: Tue Nov 16, 2004 6:27 pm
Location: Here and There
Contact:

Re: Implementing cues in M4L : needing some help...

Post by Michael Hatsis » Tue Jun 22, 2010 8:28 pm

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

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. 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, \
mike

Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Re: Implementing cues in M4L : needing some help...

Post by Crubier » Wed Jun 23, 2010 10:57 am

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 
var desiredPos=currentClip.Cues[currentClip.selectedCueIndex].position;

// 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
playingClipAPI.set("loop_start",desiredPos);

// 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.
playingClipAPI.call("move_playing_pos",startPos-desiredPos);

// I call "fire" so that the jump will be effective on next quantification, right on the beat.
playingClipAPI.call("fire");
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.

bobseekone
Posts: 25
Joined: Thu Apr 12, 2007 1:53 am
Location: New York

Re: Implementing cues in M4L : needing some help...

Post by bobseekone » Tue Sep 21, 2010 9:22 pm

Crubier, this device looks like something I could use. I want to display cue points attached to my clips to remind me that a new section of the song is coming up when I'm playing along with the clips. Is it possible for you to share this device? I don't need the part that adjusts the play position, I just want to be able to display what's ahead.

Thanks!

Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Re: Implementing cues in M4L : needing some help...

Post by Crubier » Wed Sep 22, 2010 7:20 am

A new version will be available soon :
It has much more functions, manages 3 tracks at once, has a clear interface, and displays much more information.
It will also be a bit trickier to learn but easier to use.

Image

Image

bobseekone
Posts: 25
Joined: Thu Apr 12, 2007 1:53 am
Location: New York

Re: Implementing cues in M4L : needing some help...

Post by bobseekone » Thu Sep 23, 2010 3:43 pm

This looks amazing! If you need someone to beta test it, I'd be happy to. Just let me know how to get it.

Gravis
Posts: 104
Joined: Sat Jul 28, 2007 4:47 am

Re: Implementing cues in M4L : needing some help...

Post by Gravis » Sun Sep 26, 2010 11:21 pm

id be really interested to get my hands on this as well and have a poke around. It's similar to an idea i have actually.
iMac G5 2.16 | Echo AudioFire12 | Xone 92 | Live 8 + M4L | Trigger Finger | Monome 256 | Kenton Killamix Mini | Truth 3031A

Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Re: Implementing cues in M4L : needing some help...

Post by Crubier » Mon Sep 27, 2010 8:12 am

While working on the last bugs before the "official" 1.0 release in august, I decided to rewrite all the Live API part, in order to improve timing accuracy.

I am now in the process of developing all the API calls that were previously in javascript into a max Patcher which handles every Live API calls, with better timing and stability. It should be done before mid-october.

A video explaning how to use the device will soon be available, since it is quite complex and powerful. I'll post it as soon as it's done.

See you soon !

bobseekone
Posts: 25
Joined: Thu Apr 12, 2007 1:53 am
Location: New York

Re: Implementing cues in M4L : needing some help...

Post by bobseekone » Mon Oct 18, 2010 4:17 pm

Just checking in to see how it's going. I'm next playing on Oct 31 and would like to get a cueing system up and running before then. I don't need the ability to jump around in the clip right now, but simply would like to be able to display a measure/beat countdown to the next section in the clip. Also need the display to be fairly big so it's easily visible.
Thanks!

Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Re: Implementing cues in M4L : needing some help...

Post by Crubier » Wed Oct 20, 2010 8:15 pm

Hi all,

I am currently optimizing the Interface to make it really easy and intuitive to use, and let me say you that it's gonna rock !
I am spending quite a lot of time on that stuff by now, since everything else (Live API, functions coding...) is fully functional.

I will post a video in about a week explaining everything, but I am not sure to release before the 31st of October. I can't promise, it depends on the time it will take me to tweak everything. I am a real perfectionist, and I want to sell the plugin for about 10-15€, thus I don't want to release a semi-finished, buggy plugin.

To give you an Idea, the full Max Patch is about 300Ko, and the Javascript is 902 lines long and counting. The whole plugin will be very, very powerful, but basic use of it is gonna be simple.

At the moment, I could sell you the plugin as-is, it would be perfect for monitoring the upcoming cue points, etc... But what would take you quite a lot of time is the creation of cue points for each song. At the moment, It takes me about 10s to place correctly and name One cue point. I am working on optimizing and automating this, in order to allow the DJ to place cue points with maximum information (name of song parts, color, position, length between points) live, only using midi controls and his monitoring system.

See you in the next few weeks !

Crubier
Posts: 51
Joined: Thu Nov 05, 2009 8:37 am
Location: Toulouse, France

Re: Implementing cues in M4L : needing some help...

Post by Crubier » Wed Nov 10, 2010 12:42 pm

Some news :

I am still developing the device, no more problems with the live API, but I am adding new functionality, enhancing the workflow and user interface in order to get a highly efficient device.
Also, the user interface will be highly customizable, to be either simple, with only 1 timing information label for each track (e.g. time to next cue point), or very complex with more than 15 timing infos for each track (e.g. loop start/end position, clip start/end position, time to next cue point, time from previous cue point, interval length between two points, loop length, more more and more, there are 121 possibilities...)

Each cue point has different attributes that can be customized in order to add information for the performer :
  • Color
    Name
    Position
    Length
    *New* Subjective intensity graph (e.g. increasing intensity for a song intro, high intensity for a solo...)
Screenshots coming soon...

Post Reply