Some ideas for maxforlive device.

For topics related to using MsPinky inside the Max/MSP graphical programming environment
Post Reply
Mudo
Posts:340
Joined:Tue Jun 08, 2004 9:22 pm
Location:...Barcelona...
Some ideas for maxforlive device.

Post by Mudo » Sat Mar 26, 2011 7:45 pm

Hi Guys!
I spent my last year learning python remote scripting basics and a bit maxmsp/pd. Now I'm focusing into maxforlive (with my new short skills) to add some interesting stuff into the max device.

First troubles, second solutions.

Trouble 1: The actual device lacks on the non-warped audio due to the LiveApi nature.

Actual approarch: After setting up the path for recorded audio in maxmsp options, the device is capable to "load" these audio into the ms. pinky object and manage these audio. Due it is getting the "original" audio source (wav file) it is not warped.

First workaround: Maybe if we set an audio channel with "resample" and route all the audio into it... we can record a "new clip" with warped material (not warped really but like frozen one). If we put these channel as focus in mfl device we can get "semi-warped" audio to play. I was trying with sends and routing "sends only" but sends hasn't "record" option. Then I set sends only and routed the send output into a new audio channel (and this to the master). I can't get you feedback because I can't set properly the path or device is not loading the "recorded" audio. More work on this will needed (and I'm doing it hehe).

Second workaround: We can set a list of observers from warp markers (I need to check if it is possible to get this info from LiveApi) and remap these info into maxforlive device. I imagine that the Ms. Pinky object must be updated to use these info but maybe we can do something with new "cues" feature.

Third approarch: Create an audio buffer and use it to manage 1,2,4,8 audio bars like this:
http://vimeo.com/9189314
All the fx, loop, sync... applied into this buffer.


Trouble 2: Controlling transport like the Bridge.

Actual approarch: At this moment we can't get control over the transport control. It is not so important because the nature of Ms. Pinky device is become a plug not a controller and we can do a lot of stuff that Serato still can't (sorry dudes).

First Workaround: We can set an observer for transport and create some nice function to modify it too.

In the first case we can use these information to things like:
Sync audio from the plug.
Improve the pitch look instead syncing (for musicallity purposes)
Improve cue functions.
Improve the related "buffered" solution listed before.

In the second case (send info to transport) we can do things like:
Control transport playback (sorry again serato dudes).

Possible Workarounds:
In the first case we can send the info about "bpm", "position", "status", "tempo signature" to define some interesting variables in our device. It is a matter of listeners and some patching.

In the second case we can "codify" vinyl timecode to talk with LiveApi. In the worst scenario, we can call "The Bridge" remote scripts and get some useful methods (emm Serato guys, very very sorry about that :roll:). It will need some LiveApi trickys but due it is inside the Live package, it could be possible. If it depends on hardware dongle (some interesting lines in log files pointing in this direction)... well, then we can wrote our own methods and that's it. We have the nice "addon" that we doesn't need hardware dongles and we can get some profit from open libraries like LiveOSC and so on.

Trouble 3: Maxforlive dependency.

Actual approarch: Due to our nature as Maxmsp dependency, the first and most reliable approarch has become maxforlive. This makes our solution a bit expensive (but still cheaper than Rane boxes) and fully potential. Maxforlive as a set of python remote scripts plus max integrated runtime and GUI has some nice methods related to LiveApi internals.

Ok, nothing really determinant. We can make the most of the related solutions with maxmsp, LiveOSC and some remote scripting (in the worst of situations) get free from maxforlive (but still integrated if we want) and again cheaper and non-dependent from c'74.


About Mixtape feature:
Actually we can record our scratch/mixed music regulary without problems. We can set any midi mixer and do the "magic" too.

Maybe integrating some nice features like "label" (from our audio inside plug) to live arrangement view or directly mapping from pitch, xfader or wathever you like will be great. It is not so much work (but think in all listed please) so what do you think about all of this?

Anyone interested in share/contribute?


-m!
...

Mudo means mute person.


Researching new interface paradigms
...
Mudo
Posts:340
Joined:Tue Jun 08, 2004 9:22 pm
Location:...Barcelona...

Post by Mudo » Mon Mar 28, 2011 1:06 am

...

Mudo means mute person.


Researching new interface paradigms
...
Post Reply