Nabble - OpenSound Control (OSC) - Dev

opensoundcontrol.org hacked/spammed?

2009-12-21T13:12:43Z

I'm flipping through the forums on opensoundcontrol.org, and seeing
lots of follow-ups looking like

"thanks so much for every info you provide us. 90 day loans desk
chairs steam cleaners"

Is there some robot signing up and posting replies?

-- N.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
soundcloud.com/cassiel
www.last.fm/music/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Vacation reply

2009-11-26T09:01:50Z

Hey ,friend I find a site to sell electronic products with very good price. Laptop ,iPhone even Motorcycle are very popular .their products are original quality with very low price as wholesale business supplier.They also can do retail business for end user now. maybe it is fit for your business . if you like you can contact them : wholesalers-electronic.com
E-mail: wholesaler318(at)188.com
Msn : wholesaler31888(at)hotmail.com

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Announce] ScalaOSC

2009-11-26T09:01:38Z

hi,

while this is still experimental and incomplete, i want to announce a
subproject of mine, ScalaOSC, which is an OpenSoundControl library
for Scala, modeled after the java library NetUtil ( http://
sourceforge.net/projects/netutil ) but with several enhancements and
refinement specific to Scala.

in this early stage, at least you can create UDP clients with 32- and
64-bit type tag support.

ScalaOSC is released unter the LGPL, and the code is currently
available via SVN as subdirectory here:

http://tintantmare.svn.sourceforge.net/viewvc/tintantmare/scalaosc/
(might be moved to a dedicated space in the future)

it is developed against the scala 2.8 nightly builds.

comments + participation welcome. the documentation is very bad in
this moment, but the javadocs of NetUtil should help a little.

the current TO-DO list:

- TCP support with client and server
- configurable codec
- specialization of OSCMessage subclasses
- more scalacheck tests
- carefully going through synchronization and multi-threading issues
- trying it out on Android
- benchmarking and possible performance enhancements
- scaladoc stuff

cheers, -sciss-

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: liblo bidirectional tcp?

2009-11-12T13:08:45Z

IOhannes m zmoelnig wrote:
> hi all.
>
>
> so my question is:
> - how do tell my server to send back a message to a connected client?
>

How did you get it there in the first place? UDP or TCP

I would use TCP because it would cause the client to open a socket and
you can communicate back through same socket.
> it would be sufficient to broadcast to all connected clients (only one
> is supposed to be connected)
>
>
I would assume you are doing that with UDP
> i understand the problem when using UDP, but really i am using TCP/IP.
> the client will be behind a natted firewall, without the possibility to
> open any ports.
>
If the client has a firewall that is stopping you opening a TCP socket,
that same firewall would most definitely stop you sending a UDP packet
> there seems to be a way to get the source of an incoming message with
> "lo_message_get_source()", but how on earth do i get lo_messages out of
> the server?
>
>
If you were to open a TCP socket, you just read the data from the socket
like you would a stream / file

--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page

http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: liblo bidirectional tcp?

2009-11-12T12:52:52Z

On Thu, Nov 12, 2009 at 3:49 PM, Andy W. Schmeder
<andy@...> wrote:

> The IP header has two fields for source and destination port.
>
> In most cases you don't specify a source port, just a destination. In
> this case the operating system automatically assigns one to your
> connection, typically with a "high number" (> 15000). When you
> traverse a NAT device, the source port gets changed and the NAT router
> maintains a table of which address to forward packets based on their
> source port.
>
> When your server receives a packet, it simply swaps the source and
> destination ports to make a packet that will travel in the other
> direction. This packet will arrive at the client regardless of how
> many NAT devices are in between. This works for both UDP and TCP.
> Services like Skype (and also Ross Bencinas' oscgroups server) use a
> special technique called NAT hole punching that uses an intermediary
> to relay what the NAT holes are between to clients. Unless you have
> an ultra-restrictive firewall this will pretty much always work.
>
> When you use the function recv() you can't make a reply packet because
> the source port isn't provided. The function recvfrom() is identical
> but also fills a structure (passed by reference) with extra
> information about the source of the packet, including the address and
> source port. Meanwhile the client will need to find out what port the
> OS assigned to them, and start listening for a reply packet on that
> port.
>
> Many OSC libraries have "forgotten" about bidirectional UDP, but this
> is actually the basis of how the internet works (DNS would never work
> without it, for example). Anyways I don't know how its done in liblo,
> but hopefully this helps....

liblo uses recvfrom() for UDP, and recv() for TCP. I'll have to test
sometime to see if it's possible to "reply" on a TCP connection...

It should perhaps be added as a unit test, now that TCP is better supported.

Steve
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: liblo bidirectional tcp?

2009-11-12T12:49:06Z

The IP header has two fields for source and destination port.

In most cases you don't specify a source port, just a destination. In
this case the operating system automatically assigns one to your
connection, typically with a "high number" (> 15000). When you
traverse a NAT device, the source port gets changed and the NAT router
maintains a table of which address to forward packets based on their
source port.

When your server receives a packet, it simply swaps the source and
destination ports to make a packet that will travel in the other
direction. This packet will arrive at the client regardless of how
many NAT devices are in between. This works for both UDP and TCP.
Services like Skype (and also Ross Bencinas' oscgroups server) use a
special technique called NAT hole punching that uses an intermediary
to relay what the NAT holes are between to clients. Unless you have
an ultra-restrictive firewall this will pretty much always work.

When you use the function recv() you can't make a reply packet because
the source port isn't provided. The function recvfrom() is identical
but also fills a structure (passed by reference) with extra
information about the source of the packet, including the address and
source port. Meanwhile the client will need to find out what port the
OS assigned to them, and start listening for a reply packet on that
port.

Many OSC libraries have "forgotten" about bidirectional UDP, but this
is actually the basis of how the internet works (DNS would never work
without it, for example). Anyways I don't know how its done in liblo,
but hopefully this helps....

Andy.

On Nov 12, 2009, at 12:07 PM, IOhannes m zmoelnig wrote:

> hi all.
>
> sorry if this comes through twice; i keep using the wrong address for
> sending emails...
>
> for my midi-over-osc project i have to establish a bidirectional
> communication over WAN.
>
> i wanted to use liblo for this, but have trouble finding the relevant
> information in the API-documentation.
>
> so my question is:
> - how do tell my server to send back a message to a connected client?
> it would be sufficient to broadcast to all connected clients (only one
> is supposed to be connected)
>
> i understand the problem when using UDP, but really i am using TCP/IP.
> the client will be behind a natted firewall, without the possibility
> to
> open any ports.
>
> there seems to be a way to get the source of an incoming message with
> "lo_message_get_source()", but how on earth do i get lo_messages out
> of
> the server?

---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: liblo bidirectional tcp?

2009-11-12T12:46:30Z

On Thu, Nov 12, 2009 at 3:07 PM, IOhannes m zmoelnig <zmoelnig@...> wrote:

I'm afraid it's not directly supported. The problem is liblo has two
different data structures for sending and receiving (lo_address and
lo_server). When you send a message it creates a socket, but there's
currently no way to tell a server to use the same socket as a given
lo_address.

I just looked up the last time someone asked me about this (off-list),
we came up with a suggestion that one should be able to specify this
relationship, like:

s = lo_server_new_with_proto(...);
a = lo_address_new_with_proto(...);
lo_server_set_address(s, a);

But this hasn't been implemented.. I'm trying to remember now why, but
for some reason we determined that lo_send_from() wasn't a solution to
this problem.

In any case, as things stand you have to create two uni-directional
TCP connections.

Note that I've never received feedback from anyone telling me whether
the TCP implementation works well or not, so beyond my limited testing
I'd love to see any reports of bad behaviour.

> so my question is:
> - how do tell my server to send back a message to a connected client?
> it would be sufficient to broadcast to all connected clients (only one
> is supposed to be connected)
>
> i understand the problem when using UDP, but really i am using TCP/IP.
> the client will be behind a natted firewall, without the possibility to
> open any ports.

Okay, that's a pretty good reason to need this feature...

> there seems to be a way to get the source of an incoming message with
> "lo_message_get_source()", but how on earth do i get lo_messages out of
> the server?

I'm not sure I understand this question.. the server calls a callback
when it gets a message, you don't "get messages out" of a server.

> PS: the project is due tomorrow, so i'm a bit stressed :-)

That sucks! Good luck, you might have to hack it for now! (For
instance, modify the liblo code internally for a temporary fix.. like,
add a function to pass around the socket fd.)

By the way, speaking of hacks, I should mention that liblo 0.26
supports parsing and dispatching messages from memory, as well as
serializing messages to memory, so you could actually use this
functionality to send and receive the data using your own networking
code.

Look at lo_message_serialise() and lo_server_dispatch_data().

> PPS: i'm not on the liblo-devel list as i fail to find the subscribe
> info on sourceforge. please CC me.
> i _am_ subscribed on osc_dev@create)

It's linked on the liblo homepage:

https://lists.sourceforge.net/lists/listinfo/liblo-devel

Steve
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: liblo bidirectional tcp?

2009-11-12T12:38:36Z

IOhannes m zmoelnig wrote:

> hi all.
>
> sorry if this comes through twice; i keep using the wrong address for
> sending emails...
>
> for my midi-over-osc project i have to establish a bidirectional
> communication over WAN.
>
> i wanted to use liblo for this, but have trouble finding the relevant
> information in the API-documentation.
>
> so my question is:
> - how do tell my server to send back a message to a connected client?
> it would be sufficient to broadcast to all connected clients (only one
> is supposed to be connected)
>
> i understand the problem when using UDP, but really i am using TCP/IP.
> the client will be behind a natted firewall, without the possibility to
> open any ports.
>
> there seems to be a way to get the source of an incoming message with
> "lo_message_get_source()", but how on earth do i get lo_messages out of
> the server?

hmm, seems i missed the obvious.
for whatever reasons i read:
typedef int(* lo_method_handler)(const char *path, const char *types,
lo_arg **argv, int argc, void *data, void *user_data)

rather than:
typedef int(* lo_method_handler)(const char *path, const char *types,
lo_arg **argv, int argc, lo_message msg, void *user_data)

and there i get the lo_message (including the sender) just fine.

mfgadt
IOhannes

>
>
> mfgaser
> IOhannes
>
> PS: the project is due tomorrow, so i'm a bit stressed :-)
>
> PPS: i'm not on the liblo-devel list as i fail to find the subscribe
> info on sourceforge. please CC me.
> i _am_ subscribed on osc_dev@create)
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

smime.p7s (4K) Download Attachment

Re: MIDI over OSC

2009-11-12T12:20:22Z

On Fri, Nov 6, 2009 at 11:11 PM, Andy W. Schmeder
<andy@...> wrote:
>
> To my knowledge, the types "S", "c", "r", "m" and "[", "]" are rarely
> if ever used.
>

'[' and ']' are used extensively in oscit to discover methods. This is
an example of a reply (describes the type and current value of 8
urls):

[s[*s]][s[sss]][s[sss]][s[sss]][s[sss]][s[sss]][s[ssss]][s[fffss]]

This would be impossible without '[' and ']' delimiters (and without
using a blob).

Gaspard
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

liblo bidirectional tcp?

2009-11-12T12:07:18Z

hi all.

sorry if this comes through twice; i keep using the wrong address for
sending emails...

for my midi-over-osc project i have to establish a bidirectional
communication over WAN.

i wanted to use liblo for this, but have trouble finding the relevant
information in the API-documentation.

so my question is:
- how do tell my server to send back a message to a connected client?
it would be sufficient to broadcast to all connected clients (only one
is supposed to be connected)

i understand the problem when using UDP, but really i am using TCP/IP.
the client will be behind a natted firewall, without the possibility to
open any ports.

there seems to be a way to get the source of an incoming message with
"lo_message_get_source()", but how on earth do i get lo_messages out of
the server?

mfgaser
IOhannes

PS: the project is due tomorrow, so i'm a bit stressed :-)

PPS: i'm not on the liblo-devel list as i fail to find the subscribe
info on sourceforge. please CC me.
i _am_ subscribed on osc_dev@create)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

smime.p7s (4K) Download Attachment

Re: MIDI over OSC

2009-11-06T14:11:00Z

> or is a single midi atom meant to hold an entire midi-message (zero
> padded)?
> the above example would then be "144 60 64 0" "128 60 0 0"

This would be my interpretation. Unfortunately there are no more
details available.

> what about sysex then?

No idea, probably that wasn't anticipated.

To my knowledge, the types "S", "c", "r", "m" and "[", "]" are rarely
if ever used.

I am not aware of any actual OSC implementation that uses this "MIDI
word type".

Various individuals have invented encodings for OSC in MIDI that don't
use it. Here is one of them:

http://opensoundcontrol.org/implementation/osc2midi

For MIDI over networks you can use RTP-MIDI which I believe is now
supported in OSX, Windows and maybe Linux also.

> probably i'll end up simply using a blob..

I'd probably do the same.

---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

MIDI over OSC

2009-11-06T13:11:48Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi all

for a project, i have to transmit MIDI over the network and i will use
OSC (either using Pd or a liblo app) for that.

looking at the specs, i find that there is already a MIDI-type (i never
needed _that_)
however i don't understand the reasoning, why this MIDI packet consists
of 4 MIDI bytes.

is this meant to be a raw midi stream zero-padded at the end?
e.g. sending "144 60 64 128 60 0" would be packeted as
"144 60 64 128" and "60 0 0 0"??

or is a single midi atom meant to hold an entire midi-message (zero
padded)?
the above example would then be "144 60 64 0" "128 60 0 0"
what about sysex then?

i guess the 4-byte alignment was thought with processing performance in
mind. but then we have single chars as well...

probably i'll end up simply using a blob..

mgasdr
IOhannes

PS: i don't like MIDI either
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr0kMcACgkQkX2Xpv6ydvSojgCfSr+T8O/SPscJOgRGnWSZ771a
taMAn2D9MukntyNxR6S54CBQZ8yLlxlQ
=1bWi
-----END PGP SIGNATURE-----
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: osc over rtp

2009-11-04T11:01:20Z

> None that I am aware of.
>
> Please report back if you make some progress!
>
>
>
>
> On Nov 4, 2009, at 10:30 AM, Tristan Matthews wrote:
>
>> Hi all,
>>
>> I was just wondering if anyone knew of any implementations of OSC
>> over RTP. Here's the relevant RFC:
>> http://tools.ietf.org/html/rfc3550
>>
>> I was thinking of making an rtp payloader/depayloader for OSC with
>> gstreamer, but I wanted some feedback before starting this.

You might tunnel OSC messages as MIDI then you can use MIDI RTP.
I have discussed a design of this with John Lazzarro inventor of MIDI RTP.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: osc over rtp

2009-11-04T10:59:06Z

None that I am aware of.

Please report back if you make some progress!

On Nov 4, 2009, at 10:30 AM, Tristan Matthews wrote:

Hi all,

I was just wondering if anyone knew of any implementations of OSC over RTP. Here's the relevant RFC:
http://tools.ietf.org/html/rfc3550

I was thinking of making an rtp payloader/depayloader for OSC with gstreamer, but I wanted some feedback before starting this.

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

Programmer/Analyst II

Research Group

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

osc over rtp

2009-11-04T10:30:52Z

Hi all,

I was just wondering if anyone knew of any implementations of OSC over RTP. Here's the relevant RFC:
http://tools.ietf.org/html/rfc3550

I was thinking of making an rtp payloader/depayloader for OSC with gstreamer, but I wanted some feedback before starting this.

Thanks,
Tristan

--
Tristan Matthews
email: tristan@...
web: http://tristanswork.blogspot.com

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC's implementation in hardware??

2009-10-10T01:01:28Z

I am working on a port of liboscit (http://rubyk.org) to a DIGI
"network connector" running linux (http://bit.ly/11MXzj). You need a
true microprocessor for liboscit but you will gain lots of things:
automatic discovery on the network, applications for remote control
(iPhone, desktop and plug & play (no configuration) compatibility with
other oscit compliant hardware / software + you can use the processor
to easily code your hardware.

Our roadmap is to pause the digi development until we finish the
iPhone app prototype (November) and then have a working digi+iphone
setup by February 2010.

If you feel this could be an option, I'd be glad to help make it real !

Gaspard

On Fri, Oct 9, 2009 at 10:46 PM, Andy W. Schmeder
<andy@...> wrote:

> You may be interested in micro-OSC, an implementation of OSC on a PIC
> microcontroller.
> http://cnmat.berkeley.edu/research/uosc
>
> Source code is available--if you want it you will need to make an account on
> the CNMAT website and then let me know the account name and that you want
> access.
>
> On Oct 9, 2009, at 12:20 PM, Oscar Tuxpan wrote:
>
> Hi!!
>
> I am designing a sequencer hardware, and I want to implement OSC to it,
> the MIDI no longer is an option, but, what recommend to me to use in
> development cards?
> in addition, the necessary documentation of OSC.
>
> Greetings and Thanks!!
>
> ________________________________
> Conoce el reto de esta semana y y gana con Perfil de Windows
> Live _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
> ---
> Andy W. Schmeder
> andy [at] cnmat.berkeley.edu
> Programmer/Analyst II
> Research Group
> Center for New Music and Audio Technologies
> University of California at Berkeley
> http://cnmat.berkeley.edu
>
>
>
>
>
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC's implementation in hardware??

2009-10-09T13:46:57Z

You may be interested in micro-OSC, an implementation of OSC on a PIC microcontroller.

http://cnmat.berkeley.edu/research/uosc

Source code is available--if you want it you will need to make an account on the CNMAT website and then let me know the account name and that you want access.

On Oct 9, 2009, at 12:20 PM, Oscar Tuxpan wrote:

Hi!!

   I am designing a sequencer hardware, and I want to implement OSC to it,
the MIDI no longer is an option, but, what recommend to me to use in development cards?
in addition, the necessary documentation of OSC.

   Greetings and Thanks!!

Conoce el reto de esta semana y y gana con Perfil de Windows Live _______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

Programmer/Analyst II

Research Group

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

OSC's implementation in hardware??

2009-10-09T12:20:29Z

Hi!!

I am designing a sequencer hardware, and I want to implement OSC to it,
the MIDI no longer is an option, but, what recommend to me to use in development cards?
in addition, the necessary documentation of OSC.

Greetings and Thanks!!

Conoce el reto de esta semana y y gana con Perfil de Windows Live
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC and Arduino

2009-09-18T09:01:00Z

>
> Hi people!
>
> somebody has some code of example of OSC for arduino?
>

There is no complete OSC implementation yet for Arduino (anyone want to
help?).
Here is an incomplete one I found and it doesn't use the official OSC 1.1
framing wrapper which is now SLIP.

http://protolab.pbworks.com/Arduino_Osc

Also note that the standard Arduino boards have unnecessarily crippled
serial data rates so it is hard to achieve what we did with uOSC on USB
pics (1mS updates of all pins).

We are working on a good Arduino OSC solution but very slowly due to the
recent drop in State of California funding.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

OSC and Arduino

2009-09-18T08:52:25Z

Hi people!

somebody has some code of example of OSC for arduino?

Thanks!!

Comparte tus recuerdos en línea con quien tú desees quien tú desees.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: javascript library

2009-09-08T17:06:14Z

Hi,

I did a kind of wrapper for LibLo as an XPCOM object a while ago so
that I could use OSC from XULRunner applications. It's not really
anywhere near complete, but it is functional, so you might be
interested:

http://www.music.mcgill.ca/~sinclair/content/blog/communication_between_xul_and_osc

I would have preferred doing it natively in JavaScript actually but I
couldn't find a way to send and receive UDP packets directly using the
XULRunner runtime. Maybe there is a way, if anyone's interested in
researching that.

Otherwise, lately I started working on Swig bindings for LibLo. It's
not very far along yet, but when it's functional it might be useful
for enabling OSC in JavaScript. I'm not very aware of whether there
is a Swig module for any JavaScript implementations, but I imagine
it's likely there is.

Steve

On Tue, Sep 8, 2009 at 12:27 PM, john saylor<js0000@...> wrote:

> hey
>
> i had the idea to use javascript for some OSC stuff and i don't know
> that there's a javascript library anywhere for it [even one that sits
> on jquery, or some other framework].
>
> am i just missing it?
> do i need to write it?
>
> --
> \js [ - . . . ]
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

javascript library

2009-09-08T09:27:07Z

hey

i had the idea to use javascript for some OSC stuff and i don't know
that there's a javascript library anywhere for it [even one that sits
on jquery, or some other framework].

am i just missing it?
do i need to write it?

--
\js [ - . . . ]
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC for iPhone

2009-08-20T12:40:09Z

Gaspard worte:

> Hi Marcel !
>
> In oscit, there is an XCode project to build liboscit (containing
> oscpack) for the iPhone.
>
> I am currently creating an oscit remote for the iPhone so the code is
> pretty live at the moment.
>
> As I stabilize the iPhone specific code, I will add the bridge source
> files to liboscit (ObjC -- C++). Using oscit, your application would
> directly benefit from the zeroconf (service auto-discovery) part of
> oscit and its powerful Value abstraction...
>
> Gaspard

Thanks for your quick response, Gaspard!

That sounds pretty nice - oscpack itself is not that convenient to
use, since it only offers basic osc communication.

Meanwhile I managed to get the oscpack-example successfully running.
All the sudden it ran without any problems, maybe there have been some
problems within puredata not reading my ports.

Problems with my own implementation still exist, though, but I will
figure
it out soon.

Marcel
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC for iPhone (Marcel Fuchs)

2009-08-20T12:36:30Z

2009/8/20 Marcel Fuchs <captainbrainless@...>:
> > Here is an example showing how to use oscpack in Objective-C code.
> >
> > http://www.illposed.com/software/dls/cocoaoscpack.zip
>
> The Project compiles in Xcode without any errors, but seems like
> moving the fader does not do anything. I am using PureData and I am
> listening to port 57130 and 57120, but nothing happens. Is this cocoa
> project supposed to run out of the box, or do I have to precompile
> oscpack or something I don't know of?

The project compiles and runs, it does not have any other dependencies.

Your PD patch should be listening on port 57120 and needs to accept
messages to the address "/foo" (with a float argument). There's a
SuperCollider listener patch included in the zip file, but it probably
won't make much sense unless you are familiar with SC.

- sekhar

--
C. Ramakrishnan cramakrishnan@...
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC for iPhone

2009-08-20T00:28:25Z

Hi Marcel !

In oscit, there is an XCode project to build liboscit (containing
oscpack) for the iPhone.

I am currently creating an oscit remote for the iPhone so the code is
pretty live at the moment.

As I stabilize the iPhone specific code, I will add the bridge source
files to liboscit (ObjC -- C++). Using oscit, your application would
directly benefit from the zeroconf (service auto-discovery) part of
oscit and its powerful Value abstraction...

Gaspard

On Thu, Aug 20, 2009 at 3:49 AM, Marcel Fuchs<captainbrainless@...> wrote:

> I implemented the ObjCOSC library, an Objective-C wrapper on CNMAT's
> OSC-Kit, but I haven't been maintaining it because I switched to using
> oscpack 4 or 5 years ago.
>
> Here is an example showing how to use oscpack in Objective-C code.
>
> http://www.illposed.com/software/dls/cocoaoscpack.zip
>
> - sekhar
>
> The Project compiles in Xcode without any errors, but seems like
>
> moving the fader does not do anything. I am using PureData and I am
>
> listening to port 57130 and 57120, but nothing happens. Is this cocoa
>
> project supposed to run out of the box, or do I have to precompile
>
> oscpack or something I don't know of?
>
> I am very new to xcode, Obj-C and C++, and I am neither used to Unix
>
> filesystems that much - basically what I want is to include oscpack
>
> into my Obj-C project, I don't want to make it shared. I managed to
>
> build a project including oscpkack - using the correct search headers
>
> path and such, having oscpack in my project root. Running the basic
>
> example included into my main.mm does not cause problems, and I don't
>
> get any build errors- but there seems to be no output either, no matter
>
> which port I use.
>
> What is the best way to reach my objective? I've spent a lot of time
>
> on this, any help would be highly appreciated!
>
> -Marcel
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

OSC for iPhone

2009-08-19T18:49:16Z

I implemented the ObjCOSC library, an Objective-C wrapper on CNMAT's
OSC-Kit, but I haven't been maintaining it because I switched to using
oscpack 4 or 5 years ago.

Here is an example showing how to use oscpack in Objective-C code.

  http://www.illposed.com/software/dls/cocoaoscpack.zip

- sekhar

The Project compiles in Xcode without any errors, but seems like

moving the fader does not do anything. I am using PureData and I am

listening to port 57130 and 57120, but nothing happens. Is this cocoa

project supposed to run out of the box, or do I have to precompile

oscpack or something I don't know of?

I am very new to xcode, Obj-C and C++, and I am neither used to Unix

filesystems that much - basically what I want is to include oscpack

into my Obj-C project, I don't want to make it shared. I managed to

build a project including oscpkack - using the correct search headers

path and such, having oscpack in my project root. Running the basic

example included into my main.mm does not cause problems, and I don't

get any build errors- but there seems to be no output either, no matter

which port I use.

What is the best way to reach my objective? I've spent a lot of time

on this, any help would be highly appreciated!

-Marcel

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC 1.1 Specification: Arrays

2009-08-19T01:41:07Z

I am currently building an iPhone application to test the oscit
protocol and library. Array support was mandatory in order to save
bandwidth and processing. Parsing typetags like
"[s[s[s[*s]][s[sss]][s[sss]][s[sss]][s[sss]][s[sss]][s[ssss]][s[fffss]]]]"
is not unusual as replies when discovering urls and what they do.

In order to use array markers, I had to add the type tags '[' and ']'
to oscpack and adapt the parser (osc--> Value) for recursion.

If you need more complex data types, there is also a fast json
implementation based on ragel (json --> Value ---> json) so it's easy
to transform data to json and send it all as a single string (or to
save it on disk).

Since the code is released under an MIT licence, feel free to reuse
all or parts of the parsing code.

Gaspard

On Tue, Aug 18, 2009 at 10:40 PM, Jamie Bullock<jamie@...> wrote:

>
> Personally, I've given up trying to use OSC for structured data.
> Instead I generally run two parallel services -- XML-RPC for
> structured data and OSC over UDP for 'control' messages. Choosing the
> right tool for the job seems better than trying to make a circle fit
> in a square hole!
>
> Jamie
>
> --
> http://www.jamiebullock.com
>
>
>
> On 12 Aug 2009, at 11:08, Julian Rohrhuber wrote:
>
>> Ok, this makes sense. It would not be good to require it, I guess. It
>> could be encouraged though, since it seems to make sense whenever
>> there is structural data being exchanged.
>>
>>> The [ ] typetags are already on the list of optional types from OSC
>>> 1.0, several implementations support it, and its existing semantics
>>> are adequately documented.
>>>
>>> Certainly it has some applications but I'm not sure that it should be
>>> moved up to "required" status. OSC doesn't handle highly structured
>>> data very well anyways (in particular at the message-level), would
>>> this make that much of a difference?
>>>
>>>
>>> On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote:
>>>
>>>> Implementation should be usually straightforward. In SuperCollider,
>>>> the bracket-chars [ ] are already used to send arrayed arguments to
>>>> the server, and there is a client side implementation to support
>>>> arbitrary nesting of lists.
>>>
>>> ---
>>>
>>> Andy W. Schmeder
>>> andy [at] cnmat.berkeley.edu
>>>
>>> Programmer/Analyst II
>>> Research Group
>>> Center for New Music and Audio Technologies
>>> University of California at Berkeley
>>> http://cnmat.berkeley.edu
>>>
>>>
>>> _______________________________________________
>>> OSC_dev mailing list
>>> OSC_dev@...
>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>>
>>
>> --
>>
>>
>>
>>
>>
>> .
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev@...
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC 1.1 Specification: Arrays

2009-08-18T21:09:06Z

Makes sense. A little bit of structure though as a convention
wouldn't hurt - after all it is much easier to implement arrays in
osc than an xml parser, and it is faster as well I guess.

>Personally, I've given up trying to use OSC for structured data.
>Instead I generally run two parallel services -- XML-RPC for
>structured data and OSC over UDP for 'control' messages. Choosing the
>right tool for the job seems better than trying to make a circle fit
>in a square hole!
>
>Jamie
>
>--
>http://www.jamiebullock.com
>
>
>
>On 12 Aug 2009, at 11:08, Julian Rohrhuber wrote:
>
>> Ok, this makes sense. It would not be good to require it, I guess. It
>> could be encouraged though, since it seems to make sense whenever
>> there is structural data being exchanged.
>>
>>> The [ ] typetags are already on the list of optional types from OSC
>>> 1.0, several implementations support it, and its existing semantics
>>> are adequately documented.
>>>
>>> Certainly it has some applications but I'm not sure that it should be
>>> moved up to "required" status. OSC doesn't handle highly structured
>>> data very well anyways (in particular at the message-level), would
>>> this make that much of a difference?
>>>
>>>
>>> On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote:
>>>
>>>> Implementation should be usually straightforward. In SuperCollider,
>>>> the bracket-chars [ ] are already used to send arrayed arguments to
>>>> the server, and there is a client side implementation to support
>>>> arbitrary nesting of lists.
>>>
>>> ---
>>>
>>> Andy W. Schmeder
>>> andy [at] cnmat.berkeley.edu
>>>
>>> Programmer/Analyst II
>>> Research Group
>>> Center for New Music and Audio Technologies
>>> University of California at Berkeley
>>> http://cnmat.berkeley.edu
>>>
>>>
>>> _______________________________________________
>>> OSC_dev mailing list
>>> OSC_dev@...
>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>>
>>
>> --
>>
>>
>>
>>
>>
>> .
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev@...
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>_______________________________________________
>OSC_dev mailing list
>OSC_dev@...
>http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

--

.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC 1.1 Specification: Arrays

2009-08-18T13:40:48Z

Personally, I've given up trying to use OSC for structured data.
Instead I generally run two parallel services -- XML-RPC for
structured data and OSC over UDP for 'control' messages. Choosing the
right tool for the job seems better than trying to make a circle fit
in a square hole!

Jamie

--
http://www.jamiebullock.com

On 12 Aug 2009, at 11:08, Julian Rohrhuber wrote:

> Ok, this makes sense. It would not be good to require it, I guess. It
> could be encouraged though, since it seems to make sense whenever
> there is structural data being exchanged.
>
>> The [ ] typetags are already on the list of optional types from OSC
>> 1.0, several implementations support it, and its existing semantics
>> are adequately documented.
>>
>> Certainly it has some applications but I'm not sure that it should be
>> moved up to "required" status. OSC doesn't handle highly structured
>> data very well anyways (in particular at the message-level), would
>> this make that much of a difference?
>>
>>
>> On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote:
>>
>>> Implementation should be usually straightforward. In SuperCollider,
>>> the bracket-chars [ ] are already used to send arrayed arguments to
>>> the server, and there is a client side implementation to support
>>> arbitrary nesting of lists.
>>
>> ---
>>
>> Andy W. Schmeder
>> andy [at] cnmat.berkeley.edu
>>
>> Programmer/Analyst II
>> Research Group
>> Center for New Music and Audio Technologies
>> University of California at Berkeley
>> http://cnmat.berkeley.edu
>>
>>
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev@...
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>
> --
>
>
>
>
>
> .
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Joachim Haas ist außer Haus.

2009-08-14T14:53:47Z

Ich werde ab 14.08.2009 nicht im Büro sein. Ich kehre zurück am
14.09.2009.

Bitte wenden sie sich direkt an unser Büro:
Stefanie.Haupt@...
Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: oscpack TCP

2009-08-14T10:33:39Z

>Hi Adrian; Where is the source code for uOSC? I only see pic HEX files

In our repository.
Just register on CNMAT's web site and we will add you to the uOSC group to access it.

>in the download. Also, is for-profit distribution of uOSC restricted?
>The license implies that.
There is no intention to restrict commercial use. We use the standard language required by UC Berkeley which may need some clarification I am not qualified to do over the mailing list. It has never got in the way of any of the commercial users of OSC so far.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: oscpack TCP

2009-08-14T10:10:31Z

Hi Adrian; Where is the source code for uOSC? I only see pic HEX files
in the download. Also, is for-profit distribution of uOSC restricted?
The license implies that.

Regards,
Jeff

On 2009-Aug-14, at 10:01 AM, Adrian Freed wrote:

> Thanks Andy and Roger for providing the background to clarify the
> questions raised.
> I would just like to add that the source code is available for
> various implementations of OSC with slip (e.g. uOSC and Make
> Controller) and we have been using it for years both on high
> performance computers and very cheap microcontrollers. uOSC even
> supports pattern matching, floating point types and time tags as
> required by the specification on 8-bit microcontrollers without a
> crystal clock.
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: oscpack TCP

2009-08-14T10:01:27Z

Thanks Andy and Roger for providing the background to clarify the questions raised.
I would just like to add that the source code is available for various implementations of OSC with slip (e.g. uOSC and Make Controller) and we have been using it for years both on high performance computers and very cheap microcontrollers. uOSC even supports pattern matching, floating point types and time tags as required by the specification on 8-bit microcontrollers without a crystal clock.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Joachim Haas ist außer Haus.

2009-08-14T08:52:58Z

Ich werde ab 14.08.2009 nicht im Büro sein. Ich kehre zurück am
14.09.2009.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: oscpack TCP

2009-08-14T06:44:55Z

Andy,
Thanks for the summary. I used an X-terminal at home that ran SLIP
over a modem many years ago, but I never looked into the protocol. Your
comments about small buffers made me wonder how you could use SLIP in
place of TCP/IP without saving messages for retransmission. The answer
is simple, but something I didn't realize from recent posts here, so
maybe this will clarify some of the discussion:

SLIP is a protocol for TCP/IP datagram packets over serial channels. The
key idea is to insert SLIP END characters into the stream to delineate
packet boundaries. It does not provide error detection or retransmission
like TCP/IP, so it's much more like UDP. It is (or was) common to run
TCP over SLIP to get reliable communication (with all the standard
storage, retransmission, delays, ACKs, etc.) Some recent posts here have
been confusing (at least to me) because it seems that people are
comparing apples to oranges: one issue is how to format and send
packets. The other is how to deal with unreliable communication
channels. SLIP is one approach to the former. TCP/IP is one approach to
the latter.

-Roger

Andy W. Schmeder wrote:

> One of the main reasons SLIP is "microcontroller friendly" is that it
> does not require the entire packet to ever exist in memory on the
> sender side, whereas the count-preamble requires the entire bundle to
> be accumulated in a buffer or at least its length anticipated in
> advance. Thus we can send bundles of several Kb while only using a
> few bytes of memory.
>
> Now, TCP might be guaranteed delivery, but programs are not guaranteed
> to be correct, nor are file systems, nor is your computers main memory
> unless you're lucky enough to have ECC RAM. SLIP is basically a
> foolproof scheme for packetization that works on a wide variety of
> platforms, and doesn't blow up if there is a problem. Yes, it was
> invented for something else, and that something else was eventually
> superceeded by TCP/IP, but that isn't really relevant to a discussion
> of its merits for this application.
>
> Yes SLIP might incur a little extra work since you have to look
> character at a time for the escape bytes... (note the receiver does
> not have to wait for a complete packet to begin dispatching). but...
> they are actually quite rare so it should pipeline reasonably... and,
> we have to look at the characters individually anyways to parse
> address strings, type tags, byte swapping and so on. If you are
> really that paranoid about efficiency you can "embed" the SLIP decoder
> into the OSC decoder which should give you better cache locality.
>
> BTW, double-ended SLIP (has the SLIP_END at both start and end of each
> packet) prevents passing of partial packets when a stream is
> interrupted.
>
>
>
> On Aug 13, 2009, at 3:25 PM, Adrian Freed wrote:
>
>
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev