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 !
Ms Pinky's Reformed Max-For-Live device
...
http://www.mspinky.com/phpBB2/viewtopic.php?t=992
This patch has a "video buffer" controlled by Ms Pinky.
It could be possible do the same with audio from channels inside and incoming from outside? (not from hardware with timecode of course)
http://www.youtube.com/watch?v=Gj4o5IeL34w
...
http://www.mspinky.com/phpBB2/viewtopic.php?t=992
This patch has a "video buffer" controlled by Ms Pinky.
It could be possible do the same with audio from channels inside and incoming from outside? (not from hardware with timecode of course)
http://www.youtube.com/watch?v=Gj4o5IeL34w
...
...
Mudo means mute person.
Researching new interface paradigms
...
Mudo means mute person.
Researching new interface paradigms
...
Sorry for not getting this patch up i have been making more alternations !
Heres a list of things i have added -
Temporary Cue drop (think cdj)
Cue play for floating cue point
Save Cue function - Saves the cue to the last selected cue slot
A button to load the selected song into the deck - for if you don't want to load the songs automatically as soon as you click on them.
Floating window for cue and loop buttons that allow for the cue and loop points to be midi learnt using midi notes - atm you cant midi learn the individual cue points, midi learning the cue points with a note on/off will just take you to the next cue point in the lost (as all of the buttons appear as one midi learnable object).
Floating wave file windows that stretch across the whole screen - so you can now look at your waveforms without even having that channel open. There IS a catch though, it appears the UIwaveform object doesnt take too kindly to being stretched out like this and thus trying to jump to another position of the song, making loop points and setting cue points wont work very well at all - you will still need to set your cue points, loop points and playhead skipping on the small waveform inside the object(which remains untouched) until the object is fixed to do this sort of thing(i hope it will get updated !). These floating waveforms are still however incredibly useful when your mixing.
Heres an image to ponder over as i do some more testing to make sure everything is working as described before i release this patch (i promise i wont go making any more functions until i let you guys have a rip of this !)
Heres a list of things i have added -
Temporary Cue drop (think cdj)
Cue play for floating cue point
Save Cue function - Saves the cue to the last selected cue slot
A button to load the selected song into the deck - for if you don't want to load the songs automatically as soon as you click on them.
Floating window for cue and loop buttons that allow for the cue and loop points to be midi learnt using midi notes - atm you cant midi learn the individual cue points, midi learning the cue points with a note on/off will just take you to the next cue point in the lost (as all of the buttons appear as one midi learnable object).
Floating wave file windows that stretch across the whole screen - so you can now look at your waveforms without even having that channel open. There IS a catch though, it appears the UIwaveform object doesnt take too kindly to being stretched out like this and thus trying to jump to another position of the song, making loop points and setting cue points wont work very well at all - you will still need to set your cue points, loop points and playhead skipping on the small waveform inside the object(which remains untouched) until the object is fixed to do this sort of thing(i hope it will get updated !). These floating waveforms are still however incredibly useful when your mixing.
Heres an image to ponder over as i do some more testing to make sure everything is working as described before i release this patch (i promise i wont go making any more functions until i let you guys have a rip of this !)
...
Ok, here I could find answer my question at djtt.
Let's go! What we need? BPM calculation?
edit: maybe this one could be useful for audio buffer?
http://www.maxforlive.com/library/device.php?id=246
...
Ok, here I could find answer my question at djtt.
Let's go! What we need? BPM calculation?
edit: maybe this one could be useful for audio buffer?
http://www.maxforlive.com/library/device.php?id=246
...
...
Mudo means mute person.
Researching new interface paradigms
...
Mudo means mute person.
Researching new interface paradigms
...
Yeah i need to work out how to store variables for a track then be able to the variables when the track loads. Then i will be able to do some really cool tempo based stuffMudo wrote:Let's go! What we need? BPM calculation?
The second i can work that out i will be working on all the tempo based stuff, which will definitely be fun times !
What i really want is just a way for the user to put in the tempo manually (seeings how reading/writing id3 tags is completely out of my abilities because no objects support it). Using some sort of BPM calculator algorythm would be as accurate as i would like. Also remember in this patch the audio isnt storred in a buffer~ object.Mudo wrote:...
I'm researching bpm calculation (from audio clip or taking into a buffer)
...
If you want to research something that would get us going really quickly, then id say research how to effectivly store variables inside the patcher (so they save into a file that can be reopened when the patch opens, thus keeping all the collected data). If we can work that out then we can store a beat start marker + bpm data and be able to do some cool quantize, looping and beatjumping functions just to name a few things.
...
Ok. I think maybe we must to research into LiveApi and make an .py for Ms. Pinky to manage some inside info.
Edited: Like this
http://monome.q3f.org/wiki/LiveOSC
I'm researching and I will be back!
...
Ok. I think maybe we must to research into LiveApi and make an .py for Ms. Pinky to manage some inside info.
Edited: Like this
http://monome.q3f.org/wiki/LiveOSC
I'm researching and I will be back!
...
...
Mudo means mute person.
Researching new interface paradigms
...
Mudo means mute person.
Researching new interface paradigms
...
If the Live API had gave access to the tempo of the selected clip i would just use that, but it doesnt 
I think building a python object to store this information is overkill, we should be able to do it with the standard max objects without the need for any externals.
My thinking has been to use the "Coll" Object to store this said data, as you can store and recall the data as under a name which would be the file name of the mp3. Ill play with this today to see what i can knock up
I think building a python object to store this information is overkill, we should be able to do it with the standard max objects without the need for any externals.
My thinking has been to use the "Coll" Object to store this said data, as you can store and recall the data as under a name which would be the file name of the mp3. Ill play with this today to see what i can knock up
...
I'm suggesting not fact"ing"...
but faktotum has the knowledge about DSP but he needs all of our collab to maintain the work.
Maxforlive is not really rentable than useful for community growing, u know?
He has to develop for near 5 appz (maxipatch AO, AV, PinkyVst, BinkyToy and maxforlive)...
Scott? What about GUI customization under maxmsp 5? I have some designer resources to share... what we really need (specs for develop)?
...
I'm suggesting not fact"ing"...
but faktotum has the knowledge about DSP but he needs all of our collab to maintain the work.
Maxforlive is not really rentable than useful for community growing, u know?
He has to develop for near 5 appz (maxipatch AO, AV, PinkyVst, BinkyToy and maxforlive)...
Scott? What about GUI customization under maxmsp 5? I have some designer resources to share... what we really need (specs for develop)?
...
...
Mudo means mute person.
Researching new interface paradigms
...
Mudo means mute person.
Researching new interface paradigms
...
I think i have worked out this storage and retrieval of data now using the coll object and have a pretty good idea of how to implement it into the patch
Working on this right now actually !
Heres the info i plan to implement right away -
BPM data (in floating point format)
Key - Stored as a keycode
Key 2 - Stored as a keycode, a second keycode is for programs like MIK that sometimes report 2 different keycodes.
Downbeat position (in floating point format) - this will end up working much like the beatgrid marker in Traktor and will be a very very useful piece of info to have when used with the BPM data.
Being able to store these bits of info will enable me to do some very cool stuff, look forward to sharing it with you all !
Working on this right now actually !
Heres the info i plan to implement right away -
BPM data (in floating point format)
Key - Stored as a keycode
Key 2 - Stored as a keycode, a second keycode is for programs like MIK that sometimes report 2 different keycodes.
Downbeat position (in floating point format) - this will end up working much like the beatgrid marker in Traktor and will be a very very useful piece of info to have when used with the BPM data.
Being able to store these bits of info will enable me to do some very cool stuff, look forward to sharing it with you all !