how to communicate with control surfaces

Questions and discussion about building and using Max for Live devices
ring (Simon Slowik)
Posts: 121
Joined: Fri Oct 30, 2009 3:35 pm

how to communicate with control surfaces

Post by ring (Simon Slowik) » Wed Jan 20, 2010 10:15 am

Dear users!

As it isn't well documented (or not at all) I'd like to collect information about how to deal with the control surfaces.

So far I know that a control surface has children, called controls, that represent the knobs and sliders of the hardware. And there are the components, wich are the part of ableton to be controled.

If you give an ID of a component/control to an live.object together with "getinfo", you'll see that there are almost no properties, but a lot of functions, that represent the parameters you might expect.
That's what I get from the component "TRANSPORT" of the Control Surface "GENERICSCRIPT" (the customizeable control surface for hardware that is not supported - also called "User Remote Scripts")

Code: Select all

print: info id 204
print: info type TransportComponent
print: info description Class encapsulating all functions in Live's transport section
print: info property canonical_parent GenericScript
print: info property name str
print: info property release_class_attributes function
print: info property set_register_component_callback function
print: info property set_register_timer_notification_callback function
print: info property set_request_rebuild_callback function
print: info property set_show_message_callback function
print: info property set_song_and_application function
print: info property set_unregister_timer_notification_callback function
print: info function application
print: info function disconnect
print: info function is_enabled
print: info function on_enabled_changed
print: info function on_scene_list_changed
print: info function on_selected_scene_changed
print: info function on_selected_track_changed
print: info function on_track_list_changed
print: info function set_allow_update
print: info function set_enabled
print: info function set_loop_button
print: info function set_metronome_button
print: info function set_nudge_buttons
print: info function set_overdub_button
print: info function set_play_button
print: info function set_punch_buttons
print: info function set_record_button
print: info function set_seek_buttons
print: info function set_song_position_control
print: info function set_stop_button
print: info function set_tap_tempo_button
print: info function set_tempo_control
print: info function song
print: info function update
print: info done
(And that's how I received it)
Image

Now my questions:

1. I call e.g. "call set_tempo_control 120" - it always tells me that this is a wrong syntax. But what would be the correct syntax?

2. How can I GET the parameters? Sometimes there are callback-functions, but I also don't know the valid syntax...

Thanks and cheers,

ring

julienb
Posts: 1795
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: how to communicate with control surfaces

Post by julienb » Wed Jan 20, 2010 10:50 am

sorry, I don't answer
but I just have another question: what could be the purpose of control_surfaces objects?
I mean, I made my mapping for my hardware using basic live.object, live.remote etc.
Should it be better to use control_surfaces tree?

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

Re: how to communicate with control surfaces

Post by ring (Simon Slowik) » Wed Jan 20, 2010 12:42 pm

One thing that I've recognized is that there is a strange latency thing when mapping midi to a M4l-device-parameter. Also if you give the blue hand to a M4L-device and control that via a control surface or Midi-Mapping. It only occurs with M4L devices - normal ableton devices work fine.
The update of the Parameters doesn't work. Just a little thing like the transport_status comes about 500ms late and is not reliable. (I'm using a Novation Nocturn.)
So I hope to get a workaround by that.

Another advantage of the control_surface would be that you wouldn't have to map your hardware's knobs to the parameters each time you want to use it in a live_set.
You could integrate in the M4L-device that the Paramerters always correspond to certain controls of your hardware.

Anyway, I need it.

julienb
Posts: 1795
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: how to communicate with control surfaces

Post by julienb » Wed Jan 20, 2010 12:49 pm

ring wrote:One thing that I've recognized is that there is a strange latency thing when mapping midi to a M4l-device-parameter. Also if you give the blue hand to a M4L-device and control that via a control surface or Midi-Mapping. It only occurs with M4L devices - normal ableton devices work fine.
The update of the Parameters doesn't work. Just a little thing like the transport_status comes about 500ms late and is not reliable. (I'm using a Novation Nocturn.)
So I hope to get a workaround by that.

Another advantage of the control_surface would be that you wouldn't have to map your hardware's knobs to the parameters each time you want to use it in a live_set.
You could integrate in the M4L-device that the Paramerters always correspond to certain controls of your hardware.

Anyway, I need it.
about latency,
I'm using live.remote~ as an interface between MIDI from my hardware to Live parameters... really no latency.
The same thing with live.object gives latency.
in the documentation about live.remote, we can see it doesn't involve any undo step, so it is vERY fast.

about the other things, I don't use the blue hand.
but thanks, I understood the purpose :)

mersault
Posts: 78
Joined: Sat Dec 20, 2008 8:49 am

Re: how to communicate with control surfaces

Post by mersault » Sat Jan 23, 2010 5:26 pm

I'm sorry to butt in on this thread with what may seem like such an amateur question, but -- How do you get Max For Live to recognize a non-traditional control surface... ie a joystick? The only tutorial I can find says....

"Once you've got your device plugged in, go ahead and start up MaxMSP and open the first included patch, 1.SimpleHInput. This patch demonstrates the most simple way to get HID data into Max."

I can't find a patch that say 1.SimpleHIinput!!! How do I find that! I'm a total newbie to MAX and that sucks!

Again, I know I'm not addressing the issue in this thread and for that I apologize. However, I've been desperately searching this and I can't seem to find any direct explanations!!!

Any help would be so appreciated!!!

julienb
Posts: 1795
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: how to communicate with control surfaces

Post by julienb » Sat Jan 23, 2010 5:32 pm

mersault wrote:I'm sorry to butt in on this thread with what may seem like such an amateur question, but -- How do you get Max For Live to recognize a non-traditional control surface... ie a joystick? The only tutorial I can find says....

"Once you've got your device plugged in, go ahead and start up MaxMSP and open the first included patch, 1.SimpleHInput. This patch demonstrates the most simple way to get HID data into Max."

I can't find a patch that say 1.SimpleHIinput!!! How do I find that! I'm a total newbie to MAX and that sucks!

Again, I know I'm not addressing the issue in this thread and for that I apologize. However, I've been desperately searching this and I can't seem to find any direct explanations!!!

Any help would be so appreciated!!!
USB? serial? midi? ISDN? DIALUP?

what is the joystick interface..?

halley
Posts: 40
Joined: Sun Jun 28, 2009 8:48 am

Re: how to communicate with control surfaces

Post by halley » Sat Jan 23, 2010 5:44 pm

Have a look at this thread on cycling74 forums:
http://cycling74.com/forums/topic.php?id=24021

Or just look at the 'hi' object.

it's usb (and usb is serial).
it's not midi.
I wish it was a T1 :mrgreen:
Have a look at this as well:
http://en.wikipedia.org/wiki/USB_human_ ... vice_class

Gregory Taylor
Posts: 268
Joined: Tue Sep 01, 2009 3:11 pm

Re: how to communicate with control surfaces

Post by Gregory Taylor » Sat Jan 23, 2010 6:00 pm

...or you chould choose Help > Max Help and type "joystick" into the search window and see what happens.

mersault
Posts: 78
Joined: Sat Dec 20, 2008 8:49 am

Re: how to communicate with control surfaces

Post by mersault » Sat Jan 23, 2010 6:20 pm

"..or you chould choose Help > Max Help and type "joystick" into the search window and see what happens."

...very first thing I did, but thanks for the suggestion.

"Have a look at this thread on cycling74 forums:
http://cycling74.com/forums/topic.php?id=24021"

...I read this as well. It doesn't help with the logistics - ie. what to open, where to start, etc.

I've searched through as many places as I can think of, help files, forums, etc. I'm hoping to find somebody who knows and can give me a quick runthrough on just getting it started. Thanks for all of these suggestions though. I bought Max 3 weeks ago and I'm still trying to figure this out!!!

oh, and its a usb joystick - One thing I CAN do is confirm that MAX recognizes it.

halley
Posts: 40
Joined: Sun Jun 28, 2009 8:48 am

Re: how to communicate with control surfaces

Post by halley » Sat Jan 23, 2010 9:11 pm

@mersault
Your first post has the question "How do you get Max For Live to recognize a non-traditional control surface... ie a joystick?"
Your last post has the phrase "its a usb joystick - One thing I CAN do is confirm that MAX recognizes it".

So, what's the problem now?

If Max/M4L recognizes it, it means your joystick has an output and you are able to read it,
you just have to decide what to do with it.

it's not clear what exactly are you looking for.


@julienb
about the purpose of control_surfaces objects...
the idea, with examples from the APC40 control_surface object, is that:
- every physical control on the real object has a software control object.
(Examples: Shift_Button ... 0_Arm_Button ... Crossfader ... Device_Control_3 ...)
- every logically related group of Live functions has a software component object.
(Examples: ... Channel_Strip_2 ... Master_Channel_Strip ... Transport ... Session_Overview ...)

If you want to write objects to use you control_surfaces you'll end up writing objects
like this ones or really similar to this ones anyway.
So the basic idea is:
- avoid to reinvent the wheel...
- have a certain group of functions already taken care of,
and that you can slightly modify to your own will anyway.
- whatever object you write to use your control_surfaces,
shouldn't the internal python remote control_surface script be more faster?

Also about APC's grid of 40 clips...
The APC uses the same 5 midi notes on 8 different midi channels.
The Button_Matrix object of APC40 control_surface object addresses clips by coordinates
so it's the cleanest way to deal with APC40's clip launch buttons, at least until
multiple midi channels issues inside M4L are sorted out. I know that there are ways
of bypassing the multiple channels problem, but bypassing them 'internally' seem
'cleanest' to me.




@ring
I haven't tried the set_tempo_control function,
but is it to control tempo or to assign a button/control for tempo_control?
If that's the case, have you tried passing a button/control id as argument?
If, instead, all you want to do it's set tempo of the song to 120,
then you just have to send the 'set tempo 120' message to live_set.

About all the callback-functions, we all wish we knew the exact syntax :)

julienb
Posts: 1795
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: how to communicate with control surfaces

Post by julienb » Sat Jan 23, 2010 10:27 pm

halley wrote: @julienb
about the purpose of control_surfaces objects...
the idea, with examples from the APC40 control_surface object, is that:
- every physical control on the real object has a software control object.
(Examples: Shift_Button ... 0_Arm_Button ... Crossfader ... Device_Control_3 ...)
- every logically related group of Live functions has a software component object.
(Examples: ... Channel_Strip_2 ... Master_Channel_Strip ... Transport ... Session_Overview ...)

If you want to write objects to use you control_surfaces you'll end up writing objects
like this ones or really similar to this ones anyway.
So the basic idea is:
- avoid to reinvent the wheel...
- have a certain group of functions already taken care of,
and that you can slightly modify to your own will anyway.
- whatever object you write to use your control_surfaces,
shouldn't the internal python remote control_surface script be more faster?
ok.
by using abstractions, you can also do it with a max patch.
I mean, I did that, and still doing that in my optimization steps.

btw, I'd be interested to benchmark it (python w/ control_surface tree) and compare it to my actual interface patch

halley
Posts: 40
Joined: Sun Jun 28, 2009 8:48 am

Re: how to communicate with control surfaces

Post by halley » Sun Jan 24, 2010 2:49 am

sure it's possible to do everything from scratch
the idea should be to use control_surface objects like they are some kind of 'library'.
If you can program in C/C++ you can manipulate strings by writing a bunch of modules
and functions that handle characters, but still you'd better use some string manipulation
libraries... if developed in the right way, the more a library is used the more it becames robust.

IMHO using the control_surface objects, if they turn out to be what they are supposed to be,
should be the way to go with commercial and current hardware.
Obviously for other type of controllers doing everything from scratch is the only way to go.
I'm sure that when the sysex issues get sorted out I'll organize and integrate my rather old
but incredibly sturdy PC1600x in my controlling environment. I'm absolutely sure nobody is going
to write me a control_surface object for that and I'll be happy to do it myself.

About benchmarking...
sure on one side you have the fact that M4L isn't the internal controller script,
but maybe they're so tight that nobody is able to notice any latency/delay.
sure on the other side you have the fact that normally in a customized patch
you use abstractions but often you reduce them at a minimum when optimizing it.
Anyway, the only way to do a proper benchmarking would be having access to the
ableton's python scripting environment and comparing a good number of functions
on different hardware against the same functions accessed through M4L patches.

julienb
Posts: 1795
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: how to communicate with control surfaces

Post by julienb » Sun Jan 24, 2010 7:56 am

halley wrote:sure it's possible to do everything from scratch
the idea should be to use control_surface objects like they are some kind of 'library'.
If you can program in C/C++ you can manipulate strings by writing a bunch of modules
and functions that handle characters, but still you'd better use some string manipulation
libraries... if developed in the right way, the more a library is used the more it becames robust.

IMHO using the control_surface objects, if they turn out to be what they are supposed to be,
should be the way to go with commercial and current hardware.
Obviously for other type of controllers doing everything from scratch is the only way to go.
I'm sure that when the sysex issues get sorted out I'll organize and integrate my rather old
but incredibly sturdy PC1600x in my controlling environment. I'm absolutely sure nobody is going
to write me a control_surface object for that and I'll be happy to do it myself.

About benchmarking...
sure on one side you have the fact that M4L isn't the internal controller script,
but maybe they're so tight that nobody is able to notice any latency/delay.
sure on the other side you have the fact that normally in a customized patch
you use abstractions but often you reduce them at a minimum when optimizing it.
Anyway, the only way to do a proper benchmarking would be having access to the
ableton's python scripting environment and comparing a good number of functions
on different hardware against the same functions accessed through M4L patches.
I'd be interested by all of that.
But my only way is to spend a lot of time for sounds/music etc.
I mean, I had a 2009 all technical/coding/soldering/patching. I lost a little bit the final purpose.
So, now, all works very fine. it could be simplified, improved. but it works.
and I learn that saying "it is enough, so stop it" in my head was a good thing for me.


really, if I can collaborate, I'll do.
Rewriting my whole patch could be a nice way to test/benchmark etc.
But I really won't have time for this :cry:
if you want to see my whole patch, you can send me an email as it isn't published yet. (but it will be)

Markemark
Posts: 250
Joined: Mon Jun 22, 2009 3:51 pm

Re: how to communicate with control surfaces

Post by Markemark » Mon Feb 01, 2010 9:11 am

ring wrote:Dear users!

As it isn't well documented (or not at all) I'd like to collect information about how to deal with the control surfaces.

So far I know that a control surface has children, called controls, that represent the knobs and sliders of the hardware. And there are the components, wich are the part of ableton to be controled.

If you give an ID of a component/control to an live.object together with "getinfo", you'll see that there are almost no properties, but a lot of functions, that represent the parameters you might expect.
That's what I get from the component "TRANSPORT" of the Control Surface "GENERICSCRIPT" (the customizeable control surface for hardware that is not supported - also called "User Remote Scripts")

Code: Select all

print: info id 204
print: info type TransportComponent
print: info description Class encapsulating all functions in Live's transport section
print: info property canonical_parent GenericScript
print: info property name str
print: info property release_class_attributes function
print: info property set_register_component_callback function
print: info property set_register_timer_notification_callback function
print: info property set_request_rebuild_callback function
print: info property set_show_message_callback function
print: info property set_song_and_application function
print: info property set_unregister_timer_notification_callback function
print: info function application
print: info function disconnect
print: info function is_enabled
print: info function on_enabled_changed
print: info function on_scene_list_changed
print: info function on_selected_scene_changed
print: info function on_selected_track_changed
print: info function on_track_list_changed
print: info function set_allow_update
print: info function set_enabled
print: info function set_loop_button
print: info function set_metronome_button
print: info function set_nudge_buttons
print: info function set_overdub_button
print: info function set_play_button
print: info function set_punch_buttons
print: info function set_record_button
print: info function set_seek_buttons
print: info function set_song_position_control
print: info function set_stop_button
print: info function set_tap_tempo_button
print: info function set_tempo_control
print: info function song
print: info function update
print: info done
(And that's how I received it)
Image

Now my questions:

1. I call e.g. "call set_tempo_control 120" - it always tells me that this is a wrong syntax. But what would be the correct syntax?

2. How can I GET the parameters? Sometimes there are callback-functions, but I also don't know the valid syntax...

Thanks and cheers,

ring
I like to know how to get the parameters as well. Say for instance I getinfo on the Shift_Button there is a function is_momentary, how can you change the shift button or any other for that matter to momentary?

Hanz_Petrov
Posts: 119
Joined: Sat Feb 06, 2010 2:39 pm
Contact:

Re: how to communicate with control surfaces

Post by Hanz_Petrov » Thu Mar 18, 2010 5:24 am

Hello all,

These properties and functions definitely come from the MIDI remote scripts - and the Framework classes seem to be important here. As an experiment, I modified my custom script (which is based on the Framework classes) by assigning name values to a few of the components and controls, for example:

Code: Select all

    def _setup_transport_control(self):
        is_momentary = True
        transport = TransportComponent()
        play_button = ButtonElement(is_momentary, MIDI_NOTE_TYPE, CHANNEL, 61)
        play_button.name = 'Foo_Button'
        transport.set_play_button(play_button) #ButtonElement(is_momentary, msg_type, channel, identifier)
Using ring's method, here's what Max spit out (Foo_Button is id 47):

Image

Code: Select all

print: info id 47
print: info type ButtonElement
print: info description Class representing a button a the controller
print: info property canonical_parent ProjectX
print: info property name str
print: info property release_class_attributes function
print: info property set_forwarding_callback function
print: info property set_mapping_callback function
print: info property set_register_control_callback function
print: info property set_send_midi_callback function
print: info property set_translation_callback function
print: info function clear_send_cache
print: info function connect_to
print: info function disconnect
print: info function install_connections
print: info function is_momentary
print: info function mapped_parameter
print: info function message_channel
print: info function message_identifier
print: info function message_map_mode
print: info function message_type
print: info function needs_takeover
print: info function receive_value
print: info function release_parameter
print: info function reset
print: info function send_midi
print: info function send_value
print: info function set_channel
print: info function set_feedback_delay
print: info function set_identifier
print: info function set_needs_takeover
print: info function set_report_values
print: info function status_byte
print: info function turn_off
print: info function turn_on
print: info function use_default_message
print: info done
These are all properties and methods from the Framework classes, which my script imports. Only by assigning name values to components or controls was I able to run getinfo on them, however.

Interesting, but I'm not yet convinced that this can be used for anything more than notification (unless Live allows Max to override script functions).

More detail on my investigations into the Framework classes (and an introduction to remote scripting) can be found here, for anyone interested:
http://remotescripts.blogspot.com/

Hanz
http://remotescripts.blogspot.com/ - an introduction to the Framework classes

Post Reply