[LAU] Editing zynadsuxfx/yoshimi patches?

[S. Massy]

Hi,

This is interesting; however, I wonder whether it is really relevant to
the problem we are trying to solve here.

As I understand it, we want to:
* Get a list of parameters from the engine in order to populate the
  interface.
* Send parameter changes to the engine.
* Listen for parameter changes and other events coming from the engine.

There is two-way communication but it does not closely depend on an
action-query-response-query-response-action sequence. In other words we
are using both schemas Paul described--- sending control events and
listening for external events--- without both really needing to be
closely linked. 

Or am I misunderstanding something?

Cheers,
S.M.


On Wed, May 04, 2011 at 09:53:59AM -0400, Paul Davis wrote:
> On Wed, May 4, 2011 at 9:38 AM, Lieven Moors <lievenmoors at gmail.com> wrote:
> 
> > I would like to understand better why this is the case.
> > I guess the fundamental reason would be that UDP is an
> > unsafe protocol, because it doesn't perform checks on the
> > data sent or received. But would't that make it equally unsafe
> > in both directions? Isn't this just two osc servers that are
> > sending messages towards each other?
> 
> there are two issues. one is the issue of UDP not being "reliable".
> the other is that OSC messages have no serial number on them. if you
> end up sending the same request twice and get two different responses,
> you have no idea which one actually came first unless you simply don't
> use a reliable transport layer. in that case, the one that arrived
> first is the response to the earlier request. but now you've got an
> unreliable transport layer.
> 
> > I would expect to be reasonably sure that the reply makes it
> > from one server to another, just as any other messages would.
> > Wouldn't OSC or liblo be totally broken anyway if I couldn't
> > rely on this sufficiently?
> 
> if you're using OSC with UDP transport, you have absolutely no
> guarantee of this. of course, if you are working with a wired LAN,
> this is really deeply unlikely to be an issue. but move into a
> wireless LAN let alone WAN configurations and the possibility that a
> UDP packet will simply fail to arrive gets high enough that you do
> have to take it into consideration.
> 
> the simple answer, of course, is to use OSC over TCP which I *think*
> liblo can do (and if it can't, it should be easy to make it). but this
> still doesn't address the ordering issue, because OSC itself has no
> concept of serial delivery (or even time).
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user

--