Hi,
I just wanted to start a quick poll to see if anyone's interested in seeing OSC support in future versions of Expert Sleepers plug-ins.
If you don't know what OSC is I'm guessing you're a "no" but here's a link anyway: http://opensoundcontrol.org/introduction-osc
cheers,
os.
OSC in Expert Sleepers plug-ins - useful?
-
- KVRian
- Topic Starter
- 1410 posts since 22 Mar, 2002 from UK
-
- KVRer
- 14 posts since 7 Jun, 2008
I'm using OSC for a lot of things these days, I would LOVE to see this implemented. It would allow me to more easily control AL directly through MaxMSP, and integrate my own GUI. I've done this with SooperLooper and it works much better than the MIDI implementation.
-
- KVRian
- Topic Starter
- 1410 posts since 22 Mar, 2002 from UK
Thanks for the feedback.
Could you describe how you'd expect an OSC interface to AL to look? I have no experience with OSC so I'd appreciate your input.
Could you describe how you'd expect an OSC interface to AL to look? I have no experience with OSC so I'd appreciate your input.
-
- KVRer
- 14 posts since 7 Jun, 2008
ummmm....well, I wouldn't really expect it to look like anything. My needs would be simply so I could define my own GUI embedded in another piece of software (e.g. MaxMSP) or control AL from another OSC compatible app (currently I'm playing with OSCemote on my iPod Touch....it works nicely for a lot of things).
Most important features for me would be:
user configurable port (useful also if using more than one instance of AL)
most main features of AL mapped to standard OSC commands (e.g. /pitch/inertia/n = pitch inertia setting, etc.)
AL needs to be capable of sending feedback as well as recieving commands via OSC...Playback position would be nice too, but I can't imagine how you would implement that.
Had a bit more here, I'll post it seperately.
Most important features for me would be:
user configurable port (useful also if using more than one instance of AL)
most main features of AL mapped to standard OSC commands (e.g. /pitch/inertia/n = pitch inertia setting, etc.)
AL needs to be capable of sending feedback as well as recieving commands via OSC...Playback position would be nice too, but I can't imagine how you would implement that.
Had a bit more here, I'll post it seperately.
Last edited by amounra on Wed Sep 03, 2008 5:10 am, edited 1 time in total.
-
- KVRer
- 14 posts since 7 Jun, 2008
I think I understand your question a little better now, after thinking about it for a moment.
I have limited experience, I've only used three different OSC implementations. Essentially, there's no real reason to provide a user interface for OSC operations as long as most of the MIDI implementation within AL is mirrored via OSC. The end user would be responsible for how to use it (that's me). Simple commands are easier to parse than long strings of them within MaxMSP, but I'm probably kind of novice where this is concerned.
I have limited experience, I've only used three different OSC implementations. Essentially, there's no real reason to provide a user interface for OSC operations as long as most of the MIDI implementation within AL is mirrored via OSC. The end user would be responsible for how to use it (that's me). Simple commands are easier to parse than long strings of them within MaxMSP, but I'm probably kind of novice where this is concerned.
-
- KVRian
- Topic Starter
- 1410 posts since 22 Mar, 2002 from UK
Sorry, my "what would it look like question" was misleading. I wasn't talking about user interfaces - I was meaning, what would the command strings look like?
For me the most generic thing would probably be something like
/al/setParam "Pitch" 1.0
/al/getParam "Pitch"
How would you expect it to work if you had multiple ALs loaded at once? Each one on its own port, or all listening to the same port but with an ID e.g.
/al/0/setParam "Pitch" 1.0
/al/1/setParam "Pitch" 12.0
For me the most generic thing would probably be something like
/al/setParam "Pitch" 1.0
/al/getParam "Pitch"
How would you expect it to work if you had multiple ALs loaded at once? Each one on its own port, or all listening to the same port but with an ID e.g.
/al/0/setParam "Pitch" 1.0
/al/1/setParam "Pitch" 12.0
-
- KVRer
- 14 posts since 7 Jun, 2008
O.K. I thought perhaps that was what you were after. definitely, it wold be nice if the instance were indicated, but I don't know how the instance of AL would know what its number was. This would help for sorting within a UI that encompassed more than one instance of the plugin. Honestly, though, I don't know that it's absolutely necessary, as each instance of AL would need a seperate port, and any strings descriptive of instance could be embedded AFTER they were recieved by AL.
An autoupdate call would be important, otherwise the user would have to query changeds periodically.
I think that having each instance on its own port would be ideal, as long as the send port was configurable by the user within the prefs somewhere (in case of conflicting ports).
An init callback might be nice too...something simple, just to say "yes, i'm here, and here are all my current global settings".
I'll think about it some more....there's bound to be one or two more things to consider.
An autoupdate call would be important, otherwise the user would have to query changeds periodically.
I think that having each instance on its own port would be ideal, as long as the send port was configurable by the user within the prefs somewhere (in case of conflicting ports).
An init callback might be nice too...something simple, just to say "yes, i'm here, and here are all my current global settings".
I'll think about it some more....there's bound to be one or two more things to consider.
