liblo-devel Mailing List for LibLO

Thanks for the very thorough diagnosis, Dominic. After this
discussion, I think the simplest way to avoid "complaints" like mine
would be to document the -t vs gtklick limitation, perhaps emit a
warning from klick when -t and -o are used together, and give a
two-line example of OSC usage in the man page or somewhere.

>> Not that I care so much about UNIX, I just don't like having to pull
>> UDP ports out of thin air :)
>
> And where did you get the socket filename from? ;)

Yes, I knew you'd say that :) But /tmp/klickosc has no chance of
unintentional conflict.

I wonder if there's some command-line way to pick an empty port? I
guess a script could use netstat to see the bound ports, then pick
another one, but it would be kind of ugly.

-- Dan

On Thursday 02 June 2011 08:08:32 Dan Muresan wrote:
> > One issue is that OSC is unidirectional, so gtklick will need its
> > own
> 
> But doesn't this apply to both UDP and UNIX datagram sockets? What
> seems to happen for osc.udp:// is that klick bind()s to the specified
> (-o) UDP port, gtklick connect()s to it, and also binds to a random
> UDP port (return address). This could work when klick listens on UNIX
> as well (so you'd get a half-UNIX half-UDP connection).

You're right. A mixed unix socket / UDP setup could work, although it 
doesn't really make much sense (I can only think of disadvantages).

But there is another difference between unix sockets and UDP that I 
forgot to mention. Every UDP packet contains the sender's host/port, and 
liblo makes this information available to the receiver. This is not 
strictly part of the OSC protocol, but klick uses it to reply to the 
sender.
With unix sockets the sender's address is unknown, so this scheme does 
not work. In fact, for cases like this klick already supports an 
optional reply-to address as part of all OSC messages that generate a 
reply, but gtklick doesn't use it. This should be fairly trivial to 
change though.

> Not that I care so much about UNIX, I just don't like having to pull
> UDP ports out of thin air :)

And where did you get the socket filename from? ;)

> > Unfortunately here's the real showstopper: klick only supports JACK
> > transport if it has a static tempo map. With gtklick you can change
> > the tempo at any time, and there's no fixed reference point (like
> > the beginning of the tempo map). This requires a completely
> > different method of mapping audio frames to bar/beat/tick
> > positions.
> 
> Ah. So you made klick ignore the "-t" when OSC is active. I would
> guess most people would be happy if tempo changing was disabled in
> gtklick instead :) And gtklick's stop button could naturally map to
> stopping the transport.

Actually, changing the tempo while the transport is running is exactly 
what most people asked for... And JACK transport support for gtklick is 
in the works, but I'm not going to promise any completion date.


Dominic

> One issue is that OSC is unidirectional, so gtklick will need its own

But doesn't this apply to both UDP and UNIX datagram sockets? What
seems to happen for osc.udp:// is that klick bind()s to the specified
(-o) UDP port, gtklick connect()s to it, and also binds to a random
UDP port (return address). This could work when klick listens on UNIX
as well (so you'd get a half-UNIX half-UDP connection).

Not that I care so much about UNIX, I just don't like having to pull
UDP ports out of thin air :)

> here doesn't seem to help... Anyway, you should probably just use UDP
> instead.

Indeed I was able to get

klick -o 12345 60 &
gtklick -q osc.udp://localhost:12345

to work. Having to choose ports manually is a bit annoying but it works.

> Unfortunately here's the real showstopper: klick only supports JACK
> transport if it has a static tempo map. With gtklick you can change the
> tempo at any time, and there's no fixed reference point (like the
> beginning of the tempo map). This requires a completely different method
> of mapping audio frames to bar/beat/tick positions.

Ah. So you made klick ignore the "-t" when OSC is active. I would
guess most people would be happy if tempo changing was disabled in
gtklick instead :) And gtklick's stop button could naturally map to
stopping the transport.


Best,
Dan

Hi Dan,

On Wednesday 01 June 2011 17:39:19 Dan Muresan wrote:
> Hi, I have wasted a huge amount of time trying to figure out what
> URLs liblo takes. There is no documentation, except for the odd
> mailing list result or changelog entry. Somebody must probably think
> this stuff is obvious (or fun for users to figure out on their own?)

I'm afraid what you're trying to do will not really work (yet), but I'll 
try to answer your questions one by one.

Typically OSC uses UDP ports, not unix sockets, and many functions in 
liblo (and thus klick and gtklick as well) will also accept a simple 
integer port number. For example, "1234" is equivalent to the URL 
"osc.udp://localhost:1234/".

I can't get klick/gtklick to work with unix sockets either. I'm not sure 
why, but I'll investigate.
One issue is that OSC is unidirectional, so gtklick will need its own 
OSC address in order to receive notifications from klick. That's what 
"gtklick -r" is for, but even specifying another unix socket address 
here doesn't seem to help... Anyway, you should probably just use UDP 
instead.

> For now, I'm trying to start klick and gtklick separately, to take
> advantage of klick's Jack transport option.

Unfortunately here's the real showstopper: klick only supports JACK 
transport if it has a static tempo map. With gtklick you can change the 
tempo at any time, and there's no fixed reference point (like the 
beginning of the tempo map). This requires a completely different method 
of mapping audio frames to bar/beat/tick positions.

Many people have asked for this feature, and I've already implemented 
part of it, but I don't know when I'll be able to finish it.


Cheers,

Dominic

I just tried modifying the example_client and example_server sources,
and the following URL seems to work:

osc.unix://localhost/tmp/mysocket

(It was already actually there in the example_client.c source, commented-out.)

With respect to URLs, it'd be nice to modify the "oscsend" tool to use
URLs, and make sure oscdump works with Unix sockets. (And TCP
actually.)

Steve


diff --git a/examples/example_client.c b/examples/example_client.c
index 2c8f62b..3e5eb20 100644
--- a/examples/example_client.c
+++ b/examples/example_client.c
@@ -29,8 +29,7 @@ int main(int argc, char *argv[])

     /* an address to send messages to. sometimes it is better to let the server
      * pick a port number for you by passing NULL as the last argument */
-//    lo_address t = lo_address_new_from_url(
"osc.unix://localhost/tmp/mysocket" );
-    lo_address t = lo_address_new(NULL, "7770");
+    lo_address t = lo_address_new_from_url(
"osc.unix://localhost/tmp/mysocket" );

     if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'q') {
         /* send a message with no arguments to the path /quit */
diff --git a/examples/example_server.c b/examples/example_server.c
index 0fbe773..6b4f325 100644
--- a/examples/example_server.c
+++ b/examples/example_server.c
@@ -36,7 +36,7 @@ int quit_handler(const char *path, const char
*types, lo_arg ** argv,
 int main()
 {
     /* start a new server on port 7770 */
-    lo_server_thread st = lo_server_thread_new("7770", error);
+    lo_server_thread st =
lo_server_thread_new_with_proto("/tmp/mysocket", LO_UNIX, error);

     /* add method that will match any path and args */
     lo_server_thread_add_method(st, NULL, NULL, generic_handler, NULL);


On Wed, Jun 1, 2011 at 12:01 PM, Dan Muresan <da...@gm...> wrote:
>> Have you tried osc.unix:///tmp/klick ? I'm not sure that's correct, but it looks more likely.
>
> Yes, and also
>
> osc.unix://localhost/tmp/klick
>
> and others (some with localhost:// in the middle).
>
> I dunno, maybe klick is broken. I'll have to try and track down
> Dominic (the pyliblo & klick author) -- the homepage doesn't give any
> contact info.
>
> -- Dan
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

> Have you tried osc.unix:///tmp/klick ? I'm not sure that's correct, but it looks more likely.

Yes, and also

osc.unix://localhost/tmp/klick

and others (some with localhost:// in the middle).

I dunno, maybe klick is broken. I'll have to try and track down
Dominic (the pyliblo & klick author) -- the homepage doesn't give any
contact info.

-- Dan

You're right, it should be documented somewhere.

Have you tried osc.unix:///tmp/klick ? I'm not sure that's correct, but it looks more likely.

- Steve

On 2011-06-01, at 16:39, Dan Muresan wrote:

> Hi, I have wasted a huge amount of time trying to figure out what URLs
> liblo takes. There is no documentation, except for the odd mailing
> list result or changelog entry. Somebody must probably think this
> stuff is obvious (or fun for users to figure out on their own?)
> 
> For now, I'm trying to start klick and gtklick separately, to take
> advantage of klick's Jack transport option. Naturally the klick man
> page (or home page) doesn't have even one single example -- it would
> have been too much to ask.
> 
> I've managed to get as far as
> 
> klick -t -o /tmp/klickosc 60
> 
> But then
> 
> gtklick -q osc.unix://localhost/tmp/klick
> 
> gives me
> 
> IOError: sending failed: Destination address required
> 
> Other variants that I came up with fail likewise. I'm using liblo7,
> python-liblo 0.9.1. What is the magic spell that clients must use?
> 
> 
> Thanks,
> Dan
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger. 
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today. 
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi, I have wasted a huge amount of time trying to figure out what URLs
liblo takes. There is no documentation, except for the odd mailing
list result or changelog entry. Somebody must probably think this
stuff is obvious (or fun for users to figure out on their own?)

For now, I'm trying to start klick and gtklick separately, to take
advantage of klick's Jack transport option. Naturally the klick man
page (or home page) doesn't have even one single example -- it would
have been too much to ask.

I've managed to get as far as

klick -t -o /tmp/klickosc 60

But then

gtklick -q osc.unix://localhost/tmp/klick

gives me

IOError: sending failed: Destination address required

Other variants that I came up with fail likewise. I'm using liblo7,
python-liblo 0.9.1. What is the magic spell that clients must use?


Thanks,
Dan