From: Tim E. R. <ter...@ro...> - 2011-05-06 02:00:10
|
On May 5, 2011 09:08:05 pm Tim E. Real wrote: > On May 5, 2011 07:55:40 am Florian Jung wrote: > > Am 05.05.2011 12:54, schrieb Robert Jonsson: > > > 2011/5/5 Florian Jung<flo...@we...>: > > >> On May 4, 2011 03:45:02 pm Robert Jonsson wrote: > > >>>> 2011/5/4 Florian Jung<flo...@we...>: > > >>>>> wtf? the ipc thread uses a timer?? why? > > >>>>> why not simply using select(), poll() or epoll() on the > > >>>>> communication pipes? or is communication done completely different? > > >>>>> (never had a look to that) > > >>>> > > >>>> The reason it is IPC in the first place is that we have > > >>>> syncronisation issues that somehow must be solved, otherwise we > > >>>> could just manipulate the data directly. > > >> > > >> i don't get that. why must we synchronize when manipulating MIDI > > >> lists? can't we simply use direct manipulation and mutexes? i mean, i > > >> don't think it's usual to perform large operations (like quantisation) > > >> while playing "live", so in case the mutex is locked a bit too long, > > >> you'll hear a crackle, or get xruns. i don't think this is a large > > >> problem, because it almost never happens > > > > > > Yes, you may be right that this could work. Though generally it is > > > considered very bad form to have mutexes affecting the audio thread. > > > For many use-cases it's not a problem but it is for instance a very > > > big limitation for live work. (Yes, I have used MusE live and have had > > > plans to use it even more.) > > > > could you please explain to me what "live work" is, and what is required > > for this? > > I use it live every day. Never used it for a gig, not sure if I trust a > computer enough yet to try that. Lots of people do though. > Consider also that 'recording' involves live playing (with accompaniment > tracks, monitoring etc.), more taxing on the system, so has to be smooth. > > > > I'll keep thinking about it. Adding an async message type, as you > > > mention, to be used for some operations sounds like a good idea. > > Beside this Thread method which waits (inherited by MidiSeq + > AudioPrefetch): //--------------------------------------------------------- > // send > // send request from gui to thread > // wait until request is processed > //--------------------------------------------------------- > bool Thread::sendMsg(const ThreadMsg* m) > > our Thread class already has this: > //--------------------------------------------------------- > // send > // send request from gui to thread > // do __not__ wait until request is processed > //--------------------------------------------------------- > bool Thread::sendMsg1(const void* m, int n) > > The only place using right now is audioprefetch.cpp > > > yeah, that would be a solution. however, only when coupled with the > > ability of the "worker thread" (the thread which executes the messages) > > to execute multiple messages at one cycle. maybe we could limit the > > number or even better, the time of executed messages per cycle, if that > > improves stuff somehow > > I agree with attempting bypassing of the wait in places. > > It ties in with what I've been doing and what I need to do next: > I mentioned that plugin gui controls and main vol/pan are much quicker > since I went direct rather than calling msg_xxx (although I may have to > backtrack a bit if timing becomes an issue, possibly switching to > to the non-waiting sendMsg1, rather than direct). > > But midi gui controls, such as the controller graph knobs and volume > sliders, are *still* using the waiting msg_xxx methods. So they are still > slow. Been examining the effect of going direct there. Can't say for sure > if direct will work yet, but as you can see, smooth controls are a goal of > mine ATM. So maybe the non-waiting sendMsg1 will help there. > > Tim. > **** Any STL experts reading this? Help! **** I must also mention that MusE could gain an immediate speed boost in certain places by fixing some STL code which erases while iterating. This was the cause of many bugs long ago. I read about the official cures and tried them with no luck. (The old 'grab a copy of the iterator, increment, then erase' variations.) So I was forced to use extremely safe but slow 'outer repeating loop' techniques. Do a search in MusE for the string "The loop is a safe way" ... buildMidiEventList() is one speed-sensitive place where it was used. Those are the places I marked, there are a few more unmarked. Tim. |