Re: [Protux-devel] Multiple threads

[Luciano Giordana]

I strongly suggest to delay this since this is totally new and out of priority 
plans right now, unless you
cant do the threaded building peaks without it.

Anyway, in case this is a requirement for building peaks (I honestly dont see 
it) it would be 
an attribute of Song, as you said , or, better, an static in Peak class.

On Saturday 30 August 2003 12:20, Remon Sijrier wrote:
> > Surely this is a good idea. Mixer is doing such function right now, by
> > starting independent
> > threads .
>
> Hmm, do you have any idea where to put this class, (mustux or protux) and
> well, I do not have an idea yet how to implement it.
> If you have one, please tell me, it is very important that the
> peakBuildThreads are serialized.
> Well, I have a litle bit of an idea:
>
> Add a ThreadControl class to mustux or protux, and make it an attribute of
> Song or Project?. ThreadControl starts a thread  for each type of thread
> (maybe not necassary) and makes use of QSemaphore to control the amount of
> simultaniously running threads. Don't know if this is possible, but:
> ThreadControl.cc
> <snip>
> Thread peakBuildThreadControl = new PeakBuildControlThread;
>
> PeakBuildControlThread::add_thread()
> {
> if(ThreadType == peakBuildThread)
>     PeakBuildControlThread->add(PeakBuildTread);
> <snip>
> }
> and in the logic of the peakBuildThreadControl:
> <snip>
>     while(numberOfThreadInQeue != 0)
>         'some stuff that's starting the remaining threads after a thread
> ends execution'
> <snip>
>
> > But each thread is related to a armed BUS no armed track. So if you have
> > assigned 4 armed tracks
> > from 4 different buses, you will get for independent threads.
>
> I didn't meant threads related to recording/playing, as these threads are
> private to mixer/MADM. Thats right, isn't it?
>
> > The priority matter is not important, since protux is supposed in RTC
> > mode , where all threads (and child threads)
> > have the maximum priority from the kernel, reducing the latency problem
> > and going sync'ed through recording process.
>
> (See above), but the peakBuildingProcces now is only a CPU related task,
> no more hard disk involved. For large recordings, it (still) will take a
> certain amount of time to proces the peakfiles, but for that time, you'r
> cpu is almost dying, and even with a preemptive kernel, the GUI isn't
> responding for the time the cpu is building the peakfiles. Due the fact
> that peakbuildproces is running in threads, this behaviour is reduced a
> litle, but as peakfiles are less important then GUI interactivity I wanted
> to run those threads with a lower priority.
>
> Another reason:
> Applying a destructive filter. By doing this in a thread, and give a lower
> priority, you still can use protux for editing purposes, or whatever you
> want to do with your computer while you have to wait until the filter
> proces is done. Ehm, very bad English I hope you got the point :-)
>
>
> Remon.
>
> P.S. I now really am offline until monday,
>
>
> _______________________________________________
> Protux-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/protux-devel

-- 
Best Regards
--
Luciano Giordana - Musician - Certified Java/GNU C++ Developer 
Free Software Evangelist - Project Mustux - Musician Tools for GNU/Linux
http://www.freesoftware.fsf.org/mustux
------------------------------------------------------
-- If you use closed software, you are contributing --
-- to make them the fashion/the standard . By being --
-- the standard, the  habits cannot change, and the --
-- world will keep burning billions of dollars into --
-- licenses,  which  are  produced with no phisical --
-- material.That money could be used to improve the --
-- quality of life in poor countries, for instance. --