Re: [Om-synth] issues with om

[Dave Robillard]

On Thu, 2005-15-12 at 01:09 +0100, Atte André Jensen wrote:
> Dave Robillard wrote:
> > Om itself is and always has been very strictly hard realtime safe, I can
> > tell you that.
> 
> Ok, I see. This is still a bit problematic cause I don't have a chance 
> to look at a plugin and tell how it will perform (except by trying 
> things and avoiding the worst ones). So from the users point of view om 
> is actually om-the-program-you-wrote + 
> a-bunch-of-plugins-that-make-noise. Fo instance I realized the other 
> week that the only nice sounding rotary speaker plugin has a latency at 
> about 50 ms. This has nothing to do with om, but it still means that my 
> friends will tell me "so you can't do a decent realtime organ sound in 
> that om-thingy".

Take it up with Tom.

> > These two are communication issues.  The bane of my goddamn existance,
> > frankly.  I get it occasionally too, I'll have to slow things down a
> > bit.
> > 
> > It's a fun game of randomly increasing delays littered throughout the
> > code until things usually work.  This is the one thing that makes me
> > regret the seperate client/server model.
> 
> So you're saying that they can't be fixed? Hmm. Couldn't the race be 
> avoided by having the client wait for the server to finish whatever 
> needs to be done before proceeding?

Yes, it could, but loading patches would be about 100 times slower (very
conservative estimate)

> > Dynamic voice allocation will come in the form of a special node with an
> > "activate voice" input (ie if it's high, the voice will run, or maybe
> > vice versa).  This is a very old idea as well (it came up on the LAU
> > thread about the "ultimate modular synth" before I even wrote a single
> > line of code).  Noone's really needed it yet, so I havn't bothered.
> 
> Dare I say <soft voice>"I need it"</soft voice>?

It's on the list, somewhere below actually making the damn thing work
again, and above stabilizing and releasing.

>  From where I stand some aspects of om is as rock solid as you mention. 
> But things like the communication issues are still an anoyance, and a 
> growing one when you stress the system harder.

I know.  Sometime in the future running the host in-process with the UI
will be possible, but that's avoiding the problem rather than fixing it.

There's an API addition to liblo I want to make that would make setting
the max rate of communication simple, so you can just lower it if you
have problems.  I'll have a talk with Steve about that one next time
he's around, because the communication thing is definitely a huge pain
in my ass.

Another option is to load the patches over TCP, which would properly and
completely solve all these problems, and make it work over crappy
networks to boot.

In the meantime I'll just slow it down where necessary until it works
for everyone.  I never used to get these problems, so I was probably a
bit overzealous in removing sleep()s.

> I spend most of the day trying to put my new sounds into lash sessions 
> that would restore correctly. I managed one, and had to go to the 
> rehearsal one tune short...

LASH support is a bit of a hack right now, I'll admit.  I'm not proud of
this fact, but the client/server + lash thing is an immensely
complicated problem I'm not entirely sure how to solve yet.  Anyway, the
LASH end of things should /work/ anyway, it's just the communication
thing that might screw it up.

-DR-