Re: [MSEide-MSEgui-talk] Some question about MSE thread...
> An example is here: > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/delayedstart Ha, ok sorry for previous mail. I will study it, write you later. I need a delayed thread because somethings must be done after creation of the thread and the main-loop has to wait for this before begin. Fre;D -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 14:38:15 Fred van Stappen wrote: > > An example is here: > > > > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/d > >elayedstart > > Ha, ok sorry for previous mail. > > I will study it, write you later. > > I need a delayed thread because somethings must be done after creation of > the thread and the main-loop has to wait for this before begin. > Can't it been done in constructor of the thread? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
> Can't it been done in constructor of the thread? No. Fre;D -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
> An example is here:
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/del
Hello Martin.
Ok.
Indeed, with a demo it was **much** easier (but the battle was still hard).
Conclusion:
- The main loop in the msethread (the sound): ---> perfect, fluent, no scratch,
no problems, even with lot of dsp's.
- The graphic synchro in main loop of msethread: --> perfect, fast, no problems.
- RTLevents (for pausing the thread) work like charm (I like the "GlobalEvent"
feature to pause/resume all the threads with one unique event).
Last commit of uos has in include.inc --> {.$DEFINE mse}
--> when using a mse project use msethreads and mse system.
https://github.com/fredvs/uos
commit: 52bf6b9..660737e
Last commit of StrumPract uses uos with {$DEFINE mse}.
https://github.com/fredvs/strumpract
commit: 8343c7e..28883ba
You may comment/uncomment {$DEFINE mse} and compile the project.
And compare fpc TThread vs mse msethread.
With eyes and ears.
Many thanks Martin.
Fre;D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
> > > Can't it been done in constructor of the thread? > >No. > Please explain, I am interested on the background. Huh... After creating the thread, there are other things to do, like adding input-output, setting dsp's, ... And before all that work is done, the main loop-method has to wait before to run. Of course you may add condition in the main-loop (like a "while notstarted do sleep(10)") or use a RTL pause event. But a published "run", like you did in your last commit (many thanks for this) is much more easy. ... Fre;D -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 23:03:42 Fred van Stappen wrote: > > > > Can't it been done in constructor of the thread? > > > > > >No. > > > > Please explain, I am interested on the background. > > Huh... > > After creating the thread, there are other things to do, like adding > input-output, setting dsp's, ... And before all that work is done, the main > loop-method has to wait before to run. Of course you may add condition in > the main-loop (like a "while notstarted do sleep(10)") or use a RTL pause > event. The idea is that one uses parameters of tmythread.create() or one has a main container object with the thread worker loop and where the tmsehread is a subobject like in tthreadcomp. The thread will be created after setting up the environment. The question is if you need the thread-id for further settings. I assume not. > But a published "run", like you did in your last commit (many thanks > for this) is much more easy. > "tmsethread.fstate" with its "ts_norun" flag has been placed in "private" by accident earlier. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
