OSC for VBscript and JScript

[Jeff Glatt]

I've just released a new COM component for VBscript
and JScript that supports Open Sound Control. You can
download a ZIP file containing the component install
program, docs (for using it with VBscript), and VBscript
examples:

http://home.roadrunner.com/~jgglatt/tech/easyosc_vb.zip 

Read index.htm for usage.

The Windows/Linux C sources for EasyOSC (not required
for VBscript use) is at:

http://home.roadrunner.com/~jgglatt/tech/easyosc.zip 

Moving right along. Next up will either be Python support,
or an implementation of my OSC_Synth proposal.

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

[Jamie Bullock]

On 10 Feb 2009, at 08:16, Jeff Glatt wrote:

>
>
> Moving right along. Next up will either be Python support,
> or an implementation of my OSC_Synth proposal.
>

Are you aware of the existing Python OSC implementations:

pyliblo: http://das.nasophon.de/pyliblo/

SimpleOSC: http://pypi.python.org/pypi/SimpleOSC/0.2.3

Do we need another one?

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

[Jeff Glatt]

> Are you aware of the existing Python OSC implementations:

Yep. Well actually, SimpleOSC is not a Python implementation.
pyliblo is the python "translation layer" that interfaces to
SimpleOSC. (But pyliblo itself is not a python extension
library). So what you've cited is just one Python implementation.

I also came across something that is actual Python code to
pack/unpack OSC messages. (And then presumably you'd use
some additional code to transmit messages).

These are not the same things I'm proposing. I'd be doing a
Python extension library.

> Do we need another one?

I don't know who "we" is, but for myself, I'm definitely up for
choices that do things in a truly different way. First of all, EasyOSC,
while originally very loosely based upon SimpleOSC, is actually a
very different API with different real-time performance and notably
different methodology to using its API. If it were just mostly the
same thing with a couple tweaks (like the majority of Linux distros),
then it would be a waste of time. Furthermore, what I'd be doing is
a Python extension library. I've yet to come across one of those for
OSC. So it would not be "another one". It would be the "first one".

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

[Stephen Sinclair]

On Tue, Feb 10, 2009 at 11:14 AM, Jeff Glatt <jgglatt@...> wrote:
>> Are you aware of the existing Python OSC implementations:
>
> Yep. Well actually, SimpleOSC is not a Python implementation.
> pyliblo is the python "translation layer" that interfaces to
> SimpleOSC. (But pyliblo itself is not a python extension
> library). So what you've cited is just one Python implementation.

Actually SimpleOSC is an API that sits on top of "Open SoundControl
for Python", by Daniel Holth and Clinton McChesney.  It only depends
on the Python standard library.

pyliblo is a separate project that is a Python extension (using Pyrex)
that provides bindings to LibLo.  I haven't used it myself.


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

[Jeff Glatt]

> SimpleOSC is an API that sits on top of "Open SoundControl
> for Python"

Oops. My bad. I forgot that SimpleOSC is python stuff. The name
doesn't give any hint about that, and I'm accustomed to scripting language
extensions doing that.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

On 10 Feb 2009, at 16:14, Jeff Glatt wrote:

>
>> Do we need another one?
>
> I don't know who "we" is, but for myself, I'm definitely up for
> choices that do things in a truly different way. First of all,  
> EasyOSC,
> while originally very loosely based upon SimpleOSC, is actually a
> very different API with different real-time performance and notably
> different methodology to using its API. If it were just mostly the
> same thing with a couple tweaks (like the majority of Linux distros),
> then it would be a waste of time. Furthermore, what I'd be doing is
> a Python extension library. I've yet to come across one of those for
> OSC. So it would not be "another one". It would be the "first one".

I guess my question is, what problem are you trying to solve that  
isn't already addressed by the two existing implementations (pyliblo  
and simpleOSC)?

I'm just curious...

Jamie

--
http://www.jamiebullock.com



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

[Daniel Holth]

Jamie Bullock wrote:

> On 10 Feb 2009, at 16:14, Jeff Glatt wrote:
>  
>>> Do we need another one?
>>>      
>> I don't know who "we" is, but for myself, I'm definitely up for
>> choices that do things in a truly different way. First of all,  
>> EasyOSC,
>> while originally very loosely based upon SimpleOSC, is actually a
>> very different API with different real-time performance and notably
>> different methodology to using its API. If it were just mostly the
>> same thing with a couple tweaks (like the majority of Linux distros),
>> then it would be a waste of time. Furthermore, what I'd be doing is
>> a Python extension library. I've yet to come across one of those for
>> OSC. So it would not be "another one". It would be the "first one".
>>    
>
> I guess my question is, what problem are you trying to solve that  
> isn't already addressed by the two existing implementations (pyliblo  
> and simpleOSC)?
>
> I'm just curious...
>
> Jamie

No need to spoil the fun. The beauty of OSC is that even if you don't
decide to re-use an existing library, it's so simple that you won't
waste a lot of time making your own. In fact, with all the existing
libraries' emphasis on "Simple" and "Easy" OSC, I think there is a
definite gap in the market for HardOSC, the OSC library that puts hair
on your chest!

I won't be implementing it though because I don't personally have a use
for it, so I would not have a chance to refine its API by eating my own
dog food.

By the way, most of the packages in pypi are pure Python and don't
contain any C code.

My 2c,

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

[Jeff Glatt]

> what problem are you trying to solve that  isn't already
> addressed by the two existing implementations (pyliblo  
> and simpleOSC)?

Sometimes it isn't only about solving a problem per se, as it
is about the _way_ you solve a problem. The way that you
solve a problem is particularly important if you're going to need
to reuse the solution again and again (which would be the case
for OSC app support). Having a solution that is better suited to
your needs means that you don't need to keep repeating whatever
"hacks" you did to try to make something less pertinent work for
you. It can save you time and effort.

As I mentioned before, EasyOSC is a very different API from
LIBLO, so it has its own distinct performance, footprint, and
design (for example, the way it handles/reports errors). Therefore,
whatever Python implementation I come up with will be very
different than pyliblo. (Of course, both can ultimately be used to
output the very same OSC messages. But again, that's just a
small part of what a programmer needs). SimpleOSC is written in
python. A Python extension library is not written in Python. It is
typically written in C (which will be the case for what I do). So
again, the result will be very different.

And don't forget one of the most overlooked aspects of
evaluating a package -- its documentation. Personally, I think that
a package that has incomplete or sparse documentation, or
whose docs are filled with technobabble, is almost unusable. I
put a lot of manual effort into documentation. (Often it takes me
longer to write the docs than the tool itself). I've done numerous
developer tools (ie, EasyOSC isn't the first "dev tool" that I've
done). I often solicit feedback from people who choose to use
those tools, and an often cited reason is the docs with those tools.
Docs should definitely be considered in any code audit. And I do
think EasyOSC's docs (and any associated docs I'd do) is notably
different from the other current implementations (most which use
something called Doxygen).

In conclusion, if you do a code audit of EasyOSC (or any python
implementation I'd build around it), I think you'd see plenty of
differences with the other implementations.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev