Python API Enhancements
Posted: Thu Oct 25, 2007 10:05 am
I just had a quick scan through the Beta (B7) to see if the API had changed but it looks pretty much the same, which is a real shame, so here is what i think could be added to make the API really useful.
1. Clip Object
Audio Clip
Warp mode control
Currently the Clip only has a 'warping' boolean, a warp_mode object would be great with
mode : int (0 -> beat, 1 -> Tone etc..)
param1 : int (used for beat, tone and texture modes)
param2 : int (only used for texture mode)
Reverse control
An attribute to be able to control reverse would be great.
Slice to midi method with parameters
mode : int ( Warp, bar, 1/2 etc)
preset : int
Midi Clip
notes : array of Note objects
Note attributes
start
end
length : allow both end and length to be writable and compute the other when one changes
velocity (for note on)
velocity_off (for note off)
2. Racks
Allow access to contents of racks via a chains array of chain objects.
Chain attributes
name
mixer : (MixerDevice)
key_range (range object : low and high attributes)
velocity_range (as key)
chain_range (or just called range,again a range object)
devices : array of Device objects
The rack itself needs a chain_select attribute.
That covers the instrument rack, the drum rack has more options so each instrument chain would need :
receive_note
play_note
choke_group
audio_to
Then the rack object also needs an array for the fx :
effects : array of RackSend objects with attributes :
name
mixer : MixerDevice
devices : array of Devices
audio_to : int to select output
General Features
Allow for the creation and removal of anything you can do manually in Live :
midi clips (optional filename parameter)
audio clips (required filename parameter)
devices
the methods would be best on the valid container objects, so a track can create / delete midi clips, audio clips and devices, whereas rack chains can just create / delete devices.
Also anywhere you can use an audio file its would be great to have write access to the filename so you can swap the samples. Actually you could represent audio files via File objects, so you could programmatically go through the Library / Browser and grab a file object from any audio clip and just assign it to where you want, a clip, a sampler zone, an impulse slot.
all this would make it possible to create a real online library, with rack sharing, preset sharing, tagging, rating, commenting etc.. Like a combination of Kore and the Reaktor User Library. Just imagine how amazing that would be.
of course i havent even touched on envelopes, either clip or automation envelopes. Both of those would be really useful as well then I could write my own automation smoothing functions (and other interesting stuff like value scaling, waveshaping, perlin noise etc..etc..)
It could even prove a useful means of prototyping new functions for you. The community builds something using the API, you get to see it in action and can then consider making it a native function. Bingo, free R&D for you, less complaints from us because we can solve our own problems.
its a win-win situation.
1. Clip Object
Audio Clip
Warp mode control
Currently the Clip only has a 'warping' boolean, a warp_mode object would be great with
mode : int (0 -> beat, 1 -> Tone etc..)
param1 : int (used for beat, tone and texture modes)
param2 : int (only used for texture mode)
Reverse control
An attribute to be able to control reverse would be great.
Slice to midi method with parameters
mode : int ( Warp, bar, 1/2 etc)
preset : int
Midi Clip
notes : array of Note objects
Note attributes
start
end
length : allow both end and length to be writable and compute the other when one changes
velocity (for note on)
velocity_off (for note off)
2. Racks
Allow access to contents of racks via a chains array of chain objects.
Chain attributes
name
mixer : (MixerDevice)
key_range (range object : low and high attributes)
velocity_range (as key)
chain_range (or just called range,again a range object)
devices : array of Device objects
The rack itself needs a chain_select attribute.
That covers the instrument rack, the drum rack has more options so each instrument chain would need :
receive_note
play_note
choke_group
audio_to
Then the rack object also needs an array for the fx :
effects : array of RackSend objects with attributes :
name
mixer : MixerDevice
devices : array of Devices
audio_to : int to select output
General Features
Allow for the creation and removal of anything you can do manually in Live :
midi clips (optional filename parameter)
audio clips (required filename parameter)
devices
the methods would be best on the valid container objects, so a track can create / delete midi clips, audio clips and devices, whereas rack chains can just create / delete devices.
Also anywhere you can use an audio file its would be great to have write access to the filename so you can swap the samples. Actually you could represent audio files via File objects, so you could programmatically go through the Library / Browser and grab a file object from any audio clip and just assign it to where you want, a clip, a sampler zone, an impulse slot.
all this would make it possible to create a real online library, with rack sharing, preset sharing, tagging, rating, commenting etc.. Like a combination of Kore and the Reaktor User Library. Just imagine how amazing that would be.
of course i havent even touched on envelopes, either clip or automation envelopes. Both of those would be really useful as well then I could write my own automation smoothing functions (and other interesting stuff like value scaling, waveshaping, perlin noise etc..etc..)
It could even prove a useful means of prototyping new functions for you. The community builds something using the API, you get to see it in action and can then consider making it a native function. Bingo, free R&D for you, less complaints from us because we can solve our own problems.
its a win-win situation.