Posted: Mon Mar 15, 2010 8:06 pm
Alrighty, well i have been doing some work on the patch.
I created a temp cue drop and a cue play feature and also the ability to save a temp cue into the selected cue point. My issue is that i don't think the object allows us to select a clip slot yet not actually trigger it.
What i was hoping to achieve with the code that i could drop a temporary cue then be able to save it to any of the clip slots of my choice without actually having to fire the cue slot before i save cue data into it.
So what i think would be cool is ontop of the new cue_index command that there be instead be two different commands like cue_index # (which wont jump to a cuepoint) and cue_index_fire # (which jumps to the cue point.
This sort of thing would also be useful for the loop_index command functioning in the same way so that loops can be saved without actually jumping into the loop.
Another command i would like to see would be the ability to store a user variable along with the loop and cue points data - we could use this to store BPM info, gain info, multiband EQ info(to get tracks EQing sounding consistant) or anything else users may come up with. I realize this last request could be done other ways, but it would be a really handy tool to have embedded into the object to make doing these sorts of things a lot quicker as currently there is no easy way of reading/writing all the id3 tag info a dj program needs to be able to read and write. I have been smacking my head against a wall for the last 2 weeks trying to work out how to read/write id3 tags without using the quicktime object >_< In the end i think ill just be giving up on id3 tags completely and just worry about trying to save the data internally in the patch - which is kinda sad because my mp3's are filled full of really usful id3 tag data ill have to add in manually into an internal max database >=(
I am itching to code some BPM based stuff like better on the fly looping functionality, beatjumps, quantized cue point triggering the main thing that is holding me back is my inability to be able to store and recall this data. This is my main project at the moment, trying to work out a way to rather store and recall the info quickly and easily from inside the patch or being able to call and store id3 tag data.
Ill be throwing up this patch like i said i would when i have tested it properly but atm im pretty sure its basically good to go - the code isn't very major but indeed very handy if your like me and like to avoid using your mouse for tasks at all costs !
I created a temp cue drop and a cue play feature and also the ability to save a temp cue into the selected cue point. My issue is that i don't think the object allows us to select a clip slot yet not actually trigger it.
What i was hoping to achieve with the code that i could drop a temporary cue then be able to save it to any of the clip slots of my choice without actually having to fire the cue slot before i save cue data into it.
So what i think would be cool is ontop of the new cue_index command that there be instead be two different commands like cue_index # (which wont jump to a cuepoint) and cue_index_fire # (which jumps to the cue point.
This sort of thing would also be useful for the loop_index command functioning in the same way so that loops can be saved without actually jumping into the loop.
Another command i would like to see would be the ability to store a user variable along with the loop and cue points data - we could use this to store BPM info, gain info, multiband EQ info(to get tracks EQing sounding consistant) or anything else users may come up with. I realize this last request could be done other ways, but it would be a really handy tool to have embedded into the object to make doing these sorts of things a lot quicker as currently there is no easy way of reading/writing all the id3 tag info a dj program needs to be able to read and write. I have been smacking my head against a wall for the last 2 weeks trying to work out how to read/write id3 tags without using the quicktime object >_< In the end i think ill just be giving up on id3 tags completely and just worry about trying to save the data internally in the patch - which is kinda sad because my mp3's are filled full of really usful id3 tag data ill have to add in manually into an internal max database >=(
I am itching to code some BPM based stuff like better on the fly looping functionality, beatjumps, quantized cue point triggering the main thing that is holding me back is my inability to be able to store and recall this data. This is my main project at the moment, trying to work out a way to rather store and recall the info quickly and easily from inside the patch or being able to call and store id3 tag data.
Ill be throwing up this patch like i said i would when i have tested it properly but atm im pretty sure its basically good to go - the code isn't very major but indeed very handy if your like me and like to avoid using your mouse for tasks at all costs !