[OSC_dev] Fwd: Application Profiles: oscplanet

[Stephen Sinclair]

On Tue, Dec 23, 2008 at 9:56 AM, Nicholas J Humfrey <njh at aelius.com> wrote:
>
> On 23 Dec 2008, at 10:26, Jamie Bullock wrote:
>
>> On Tue, 2008-12-23 at 09:45 +0100, salsaman at xs4all.nl wrote:
>>> On Tue, December 23, 2008 08:09, Gaspard Bucher wrote:
>>>> On Mon, Dec 22, 2008 at 10:41 PM,  <salsaman at xs4all.nl> wrote:
>>>>>
>>>>> /clip/100/start 3456
>>>>
>>>> or
>>>>
>>>> /clip.100/start 3456
>>>>
>>>> or
>>>>
>>>> /clip/current/start 3456
>>>>
>>>> Because if the 100th clip has methods, it deserves an url. The osc
>>>> urls are made to avoid indexing everywhere. We are doing some kind
>>>> of
>>>> exception with the meta methods that "index" on urls, but they are
>>>> not
>>>> used in a running application: they are used during setup.
>>>>
>>>> Gaspard
>>>
>>>
>>> As I said, I would like to do this ! How do I create a path with
>>> variables
>>> in it ? oscpack is out for me, since it is C++ only, so this leaves
>>> just
>>> liblo I think.
>>>
>>
>> Well liblo is great! I've found it to be rock-solid, and the threaded
>> server is a really nicely designed.
>>
>> I'm pretty certain it can do what you want, Steve?
>
>
> liblo can do pattern matching in the path, yes. I have never used this
> functionality though. Need to work an easy way of extracting the value
> from the path after the match.

Hm, to be clear, you can send a pattern message to LibLo and it will
find the correct method(s), but I think you can't create a method
handler with a pattern in the path, and expect it to match incoming
messages.  There was a discussion and proposed patch here:

http://sourceforge.net/mailarchive/forum.php?thread_name=4818D471.7080206%40mikewoz.com&forum_name=liblo-devel

But theoretically this adds a lot of overhead for each incoming message.

Anyways I generally find it unnecessary to use patterned path methods.
 I don't particularly like the idea of having to parse data out of the
path either, as it seems to be a not very aesthetic way to use OSC to
me.  (Using regexps on the incoming path, after it has already been
pattern-matched = ugly, should be the exception, not the rule.)

I think it's more efficient in general to use dynamic namespaces,
which is more how LibLo is designed I think.  If you have a message
like the example:

/clip/100/start 3456

Then presumably there is a data structure in memory called "clip",
maybe there are 100 of them.  Each clip, in its constructure, creates
a /start method by calling lo_server_add_method(), and on destruction
it removes it with lo_server_del_method().

That way the method gets matched correctly when the object exists,
otherwise not.  add_method takes a context pointer so you can give it
a pointer to the correct "clip" data structure.  By registering
methods for the objects that exist in memory, it's usually not
necessary to match, say, /clip/*/start and then parse out the (*) to
get 100.  The 100 is registered when the object is created.


Steve