Thread: Re: [Javaosc-development] welcome

Hi guys! I'm glad to see this finally getting off the ground.

Let me do my part of the introduction now:

I implemented JavaOSC in 2001/2002 originally because I needed to talk
to SuperCollider from Java, and I didn't see anything available for
doing so at the time. It was very basic at that time (could only send
OSC and didn't support many types), but I made it available in the
hopes that others would find it useful. 

It wasn't really designed from the start to be a full-featured OSC
class library, but as I moved to other projects I found myself needing
more OSC functionality in Java and would then implement things as
needed, and at the same time people (esp. Martin!) were sending me
code fixes/improvements.

However, since 2004, I haven't been doing very much Java development
at all -- I'm working in C/C++/Objective-C/Objective-C++ for the most
part now-a-days (and using Ross Bencina's C++ OSC library). That's why
almost all progress on the library in the last couple of years has
been due to other developers contributing code. 

But I'd be very happy to see the library continue to move
forward. Since I'm not using it for my own projects, I can't really
drive feature identification, but I'd be happy to help out with
implementation and coordination wherever possible (and who knows --
maybe I'll find myself in Java-land again in the future).

Martin schrieb:
> As for my plans and suggestions for the future:
> * I was about to try a port to Java mobile phones
> and hopefully this will need just a rewrite of some networking code.
> * regarding the transport layer, this could be made more generic in
> order to allow also things like TCP, Serial Connections or Serial over
> Bluetooth etc.

This all sounds like good stuff. Another item I would add is

* Implement a scheduler to keep track of timestamped OSC events and
invoke them at the appropriate time.

CPP schrieb:
> Anyway, we have now managed to get the code approved for open source. I will
> send a brief summary of what we did, soon. Then we can see what we can
> incorporate into the project.

That would be great.

> I was also thinking of adding support for OSC queries. Though, I am
> not sure of the official status of that. We felt a great need for
> that in my project.

Along the same lines, support for ZeroConf/Bonjour (for dynamic
discovery of OSC servers) could be good to. It looks like there's a
Java API available:

  http://www.onjava.com/pub/a/onjava/excerpt/bonjour_ch08/index.html

- sekhar

--
C. Ramakrishnan        cra...@ac...
Illposed Software    http://www.illposed.com

"Chinmay Pendharkar" schrieb:
> Do take a look through the paper, and see if it would be useful to bring in
> some of those features into javaOSC. 

I definately think so! In particular, the code to manage running the
server in a seperate thread, support for the additional data-types,
and the changes to the the parsing and dispatching (using a trie to
store the address space), and the priority queue would all be great to
incorporate.

A few questions about JOE. First, is there a reason you are using 3
threads in the multithread version? 

I would have probably implemented it differently To me, it seems more
intuitive to use 2 threads. I would have used a multiple-writer,
single-reader FIFO for communication between other threads and the one
the server runs in. The server thread would be responsible for sending
data into the socket and reading data from the socket. It would also
parse the messages and put them into a priority queue. It would the be
responsibility of the user of the library, then, to get items out of
the priority queue and have them dispatched. The user could then do
the dispatching in whatever thread is appropriate instead of having
the server spawn its own thread for dispatching.

The other comment is that maybe the namespace storage model should be
made pluggable. Using a trie is great for programs that use a
multi-level namespace, but some programs would rather use a flat
namespace (e.g., SuperCollider). In this case, a hash-based
implementation would be better.

> Also, please tell me how I should upload the source of this JOE, or
> if I should send it over email.

The best way would be if you could make your changes in the source
tree itself and make any existing JUnit tests pass and write any new
ones that are necessary. You should have Subversion access to the
source tree already. Let me know if you have any difficulty checking
out or modifying the source.

- sekhar

--
C. Ramakrishnan        cra...@ac...
Illposed Software    http://www.illposed.com

I'm having some problems with my mail server, so here's a second
try...

- sekhar

------- Forwarded Message

To: jav...@li...
Subject: JOE
From: Chandrasekhar Ramakrishnan <cra...@ac...>
In-Reply-To: Message from "Chinmay Pendharkar" <ch...@gm...> 
   of "Tue, 12 Sep 2006 07:34:23 +0800." <d32...@ma...> 
Date: Tue, 12 Sep 2006 13:09:59 -0700
Sender: ci...@so...

"Chinmay Pendharkar" schrieb:
> Do take a look through the paper, and see if it would be useful to bring in
> some of those features into javaOSC. 

I definately think so! In particular, the code to manage running the
server in a seperate thread, support for the additional data-types,
and the changes to the the parsing and dispatching (using a trie to
store the address space), and the priority queue would all be great to
incorporate.

A few questions about JOE. First, is there a reason you are using 3
threads in the multithread version? 

I would have probably implemented it differently To me, it seems more
intuitive to use 2 threads. I would have used a multiple-writer,
single-reader FIFO for communication between other threads and the one
the server runs in. The server thread would be responsible for sending
data into the socket and reading data from the socket. It would also
parse the messages and put them into a priority queue. It would the be
responsibility of the user of the library, then, to get items out of
the priority queue and have them dispatched. The user could then do
the dispatching in whatever thread is appropriate instead of having
the server spawn its own thread for dispatching.

The other comment is that maybe the namespace storage model should be
made pluggable. Using a trie is great for programs that use a
multi-level namespace, but some programs would rather use a flat
namespace (e.g., SuperCollider). In this case, a hash-based
implementation would be better.

> Also, please tell me how I should upload the source of this JOE, or
> if I should send it over email.

The best way would be if you could make your changes in the source
tree itself and make any existing JUnit tests pass and write any new
ones that are necessary. You should have Subversion access to the
source tree already. Let me know if you have any difficulty checking
out or modifying the source.

- - sekhar

- --
C. Ramakrishnan        cra...@ac...
Illposed Software    http://www.illposed.com

------- End of Forwarded Message

Hey,

I did get your earlier mail. But, I guess it's my turn to get really busy.
Anyway, here are some point..

I agree that the 3-thread model is not the best. What we were trying to do
was to extend JavaOSC with doing much code change to it. So it has ended up
being very awkward architecture. The reason for the two-thread 'server' was
that we were afraid that paring a long address in a huge tree based
multi-level namespace would consume too much time. And if the OS level
buffers for UDP packets are not big enough to hold that many packets at
once, there will be packet loss. The 2 server model avoids that by
retrieving all the packets and storing them in Java's address space. Of
course once can always overflow the JVM heap, if enough packets are being
sent. The tests done did indicate some packet loss at very high speeds of
packet transmission.

The third thread was just to support the time-stamp feature in OSC. We
thought it would be a better idea to let the server handle it than the user.
The decision was of course affected by our synthesis system's architecture.

The tree based address-space model was used for ease of interfacing with the
synthesis software that we were using. It seemed to be the most intuitive
and 'cheap' structure. Of course, for a more linear address space, hash
tables would be better data-structures. But, we realized that supporting
wild-cards tends to be difficult when using hash-tables. So if we can figure
out a method to support wild-cards over a hash-table, it would be great
idea. I can think of custom hash functions, off the top of my head. Any
other ideas?

I am not at all experience with sourceforge development. This is my first
time. So, I am sorry, if I end up doing something wrong. I have managed to
setup subversion access to the source tree. I will try to add my updates to
the tree over this weekend.

-Chinmay




On 9/14/06, Chandrasekhar Ramakrishnan <cra...@ac...> wrote:
>
>
> I'm having some problems with my mail server, so here's a second
> try...
>
> - sekhar
>
> ------- Forwarded Message
>
> To: jav...@li...
> Subject: JOE
> From: Chandrasekhar Ramakrishnan <cra...@ac...>
> In-Reply-To: Message from "Chinmay Pendharkar" <ch...@gm...>
>    of "Tue, 12 Sep 2006 07:34:23 +0800." <
> d32...@ma...>
> Date: Tue, 12 Sep 2006 13:09:59 -0700
> Sender: ci...@so...
>
> "Chinmay Pendharkar" schrieb:
> > Do take a look through the paper, and see if it would be useful to bring
> in
> > some of those features into javaOSC.
>
> I definately think so! In particular, the code to manage running the
> server in a seperate thread, support for the additional data-types,
> and the changes to the the parsing and dispatching (using a trie to
> store the address space), and the priority queue would all be great to
> incorporate.
>
> A few questions about JOE. First, is there a reason you are using 3
> threads in the multithread version?
>
> I would have probably implemented it differently To me, it seems more
> intuitive to use 2 threads. I would have used a multiple-writer,
> single-reader FIFO for communication between other threads and the one
> the server runs in. The server thread would be responsible for sending
> data into the socket and reading data from the socket. It would also
> parse the messages and put them into a priority queue. It would the be
> responsibility of the user of the library, then, to get items out of
> the priority queue and have them dispatched. The user could then do
> the dispatching in whatever thread is appropriate instead of having
> the server spawn its own thread for dispatching.
>
> The other comment is that maybe the namespace storage model should be
> made pluggable. Using a trie is great for programs that use a
> multi-level namespace, but some programs would rather use a flat
> namespace (e.g., SuperCollider). In this case, a hash-based
> implementation would be better.
>
> > Also, please tell me how I should upload the source of this JOE, or
> > if I should send it over email.
>
> The best way would be if you could make your changes in the source
> tree itself and make any existing JUnit tests pass and write any new
> ones that are necessary. You should have Subversion access to the
> source tree already. Let me know if you have any difficulty checking
> out or modifying the source.
>
> - - sekhar
>
> - --
> C. Ramakrishnan        cra...@ac...
> Illposed Software    http://www.illposed.com
>
> ------- End of Forwarded Message
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Javaosc-development mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javaosc-development
>

Hi guys,

I have been really busy with my day job these few days to look into javaosc.
However, I managed to do some brain-storming and some snooping around. While
thinking about address-space models, with respect to our discussion earlier,
I was thinking of various models we could use to speed up parsing.

Hashing is indeed a better method with a flat address space, and more
importantly for incoming messages without any wildcards. However, it seems
pretty difficult to parse wildcards using hash tables. One way we could
explore that is to define our own hashing scheme which supports wildcards.
However I cannot think of an easy way to do this. Do you have any ideas
reagrding this?

The other approach would be to maintain a parse tree as well as a
hash-table. Messages without wildcards can be parsed through the hash-table
and those with wildcards will have to be parsed through the tree. What do
you think?

As for the auto-conf, I am looking into it. Although, it is a great tool for
auto discovery of clients on network, I am not sure how much we can use it
for discovering other OSC clients on the network. I have never used it
before, so I am also not very sure myself.

Another thing that might enhance auto-config and auto-discovery of nodes is
OSC Queries. Do you have any idea what the official status is on this. And
more importantly, is it the accpeted query method in the community? I don't
have much contact with the OSC community, so I was hoping you guys could
give some suggestions.

Finally, I have a few questions about the version control in sourceforge.
How does it work? If I have some new changes that I would like to add in.
Like say a new data-type OSC-Blob. Should I check-in the changes into the
main trunk? Or do I create branches for such changes? Or do I just keep a
personal copy for now?

I have a couple of quick updates to add, OSC-Blob, and support for incoming
socket-address information to be passed to the dispatcher, and thus to the
service thread, so that it itself can reply to the message if needed. Of
course this will have to be replaced by a generic reply address when we
abstract off the communication mechanisms from the javaosc clients
themselves.

Thats all for now.

Thanks,

-Chinmay


On 9/14/06, Chinmay Pendharkar < ch...@gm...> wrote:
>
> Hey,
>
> I did get your earlier mail. But, I guess it's my turn to get really busy.
> Anyway, here are some point..
>
> I agree that the 3-thread model is not the best. What we were trying to do
> was to extend JavaOSC with doing much code change to it. So it has ended up
> being very awkward architecture. The reason for the two-thread 'server' was
> that we were afraid that paring a long address in a huge tree based
> multi-level namespace would consume too much time. And if the OS level
> buffers for UDP packets are not big enough to hold that many packets at
> once, there will be packet loss. The 2 server model avoids that by
> retrieving all the packets and storing them in Java's address space. Of
> course once can always overflow the JVM heap, if enough packets are being
> sent. The tests done did indicate some packet loss at very high speeds of
> packet transmission.
>
> The third thread was just to support the time-stamp feature in OSC. We
> thought it would be a better idea to let the server handle it than the user.
> The decision was of course affected by our synthesis system's architecture.
>
> The tree based address-space model was used for ease of interfacing with
> the synthesis software that we were using. It seemed to be the most
> intuitive and 'cheap' structure. Of course, for a more linear address space,
> hash tables would be better data-structures. But, we realized that
> supporting wild-cards tends to be difficult when using hash-tables. So if we
> can figure out a method to support wild-cards over a hash-table, it would be
> great idea. I can think of custom hash functions, off the top of my head.
> Any other ideas?
>
> I am not at all experience with sourceforge development. This is my first
> time. So, I am sorry, if I end up doing something wrong. I have managed to
> setup subversion access to the source tree. I will try to add my updates to
> the tree over this weekend.
>
> -Chinmay
>
>
>
>
> On 9/14/06, Chandrasekhar Ramakrishnan < cra...@ac...> wrote:
> >
> >
> > I'm having some problems with my mail server, so here's a second
> > try...
> >
> > - sekhar
> >
> > ------- Forwarded Message
> >
> > To: jav...@li...
> > Subject: JOE
> > From: Chandrasekhar Ramakrishnan <cra...@ac... >
> > In-Reply-To: Message from "Chinmay Pendharkar" < ch...@gm...>
> >    of "Tue, 12 Sep 2006 07:34:23 +0800." <
> > d32...@ma... >
> > Date: Tue, 12 Sep 2006 13:09:59 -0700
> > Sender: ci...@so...
> >
> > "Chinmay Pendharkar" schrieb:
> > > Do take a look through the paper, and see if it would be useful to
> > bring in
> > > some of those features into javaOSC.
> >
> > I definately think so! In particular, the code to manage running the
> > server in a seperate thread, support for the additional data-types,
> > and the changes to the the parsing and dispatching (using a trie to
> > store the address space), and the priority queue would all be great to
> > incorporate.
> >
> > A few questions about JOE. First, is there a reason you are using 3
> > threads in the multithread version?
> >
> > I would have probably implemented it differently To me, it seems more
> > intuitive to use 2 threads. I would have used a multiple-writer,
> > single-reader FIFO for communication between other threads and the one
> > the server runs in. The server thread would be responsible for sending
> > data into the socket and reading data from the socket. It would also
> > parse the messages and put them into a priority queue. It would the be
> > responsibility of the user of the library, then, to get items out of
> > the priority queue and have them dispatched. The user could then do
> > the dispatching in whatever thread is appropriate instead of having
> > the server spawn its own thread for dispatching.
> >
> > The other comment is that maybe the namespace storage model should be
> > made pluggable. Using a trie is great for programs that use a
> > multi-level namespace, but some programs would rather use a flat
> > namespace (e.g., SuperCollider). In this case, a hash-based
> > implementation would be better.
> >
> > > Also, please tell me how I should upload the source of this JOE, or
> > > if I should send it over email.
> >
> > The best way would be if you could make your changes in the source
> > tree itself and make any existing JUnit tests pass and write any new
> > ones that are necessary. You should have Subversion access to the
> > source tree already. Let me know if you have any difficulty checking
> > out or modifying the source.
> >
> > - - sekhar
> >
> > - --
> > C. Ramakrishnan         cra...@ac...
> > Illposed Software    http://www.illposed.com
> >
> > ------- End of Forwarded Message
> >
> >
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services,
> > security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Javaosc-development mailing list
> > Jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/javaosc-development
> >
>
>