Re: [MSEide-MSEgui-talk] Some question about MSE thread...
>> In order to do so FPC thread creation must be changed, I don't like to touch >> this, too dangerous because > For fpc TThread there is property Priority := tpTimeCritical. > But it has a huge impact on the number of input (audio tracks or from mic). I did not try yet multi-tracks input with mse-threads. I will test it asap. 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...
> MSEgui has an own tapplication class. fpGUI probably wold need changes for it. Yes, I know but for fpGUI that class is called fpgapplication so maybe there would not be too much conflicts. OK, I will explore it (but not know or she will kill me). 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...
> In order to do so FPC thread creation must be changed, I don't like to touch > this, too dangerous because For fpc TThread there is property Priority := tpTimeCritical. But this has no impact on the audio-pause when closing-free dialog forms. But it has a huge impact on the number of input (audio tracks or from mic). With Priority := tpTimeCritical, I can synchronize 16 tracks perfectly on my litle machine. Without Priority := tpTimeCritical (priority : default), after 6 tracks, the synchro is no more perfect. 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...
> I saw that that there are for every audio stream two threads. Huh, what, each uos_player uses only on thread ? I do not understand. (or are you talking about the thread used for the "info panel") ? Please explain, I am very interested. 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 Friday 28 July 2017 19:46:05 Fred van Stappen wrote: > > I could not reproduce the problem with "strumpract" on Linux. > > Because you have a big machine ;-) > > But on my tinny laptop, if some other threads are working (other > applications for example), it appends. > I saw that that there are for every audio stream two threads. Is this necessary? On linux you could change thread-"nice" level (needs a direct system call in order to get the Linux thread-id). AFAIK it won't work on FreeBSD. Or the application must run with higher privilegs in order to setup higher thread priority and scheduling mode. In order to do so FPC thread creation must be changed, I don't like to touch this, too dangerous because of possible changes in FPC and different versions. 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...
On Friday 28 July 2017 19:51:47 Fred van Stappen wrote: > Huh, ... , and do you think it could be possible to compile a fpGUI app > with mse console ? > MSEgui has an own tapplication class. fpGUI probably wold need changes for it. 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...
> Sure it is possible. Examples are here: > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui Ooops... Huh, ... , and do you think it could be possible to compile a fpGUI app with mse console ? 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...
> I could not reproduce the problem with "strumpract" on Linux. Because you have a big machine ;-) But on my tinny laptop, if some other threads are working (other applications for example), it appends. And, IMHO, if everything is working perfectly on a slow machine, it would not be bad for a faster. ;-) Also, all the open-source audio multi-thread applications that you can find (LMMS, Ardour, rosegarden,..) need big machine. This because all use hard gui widget-set (Gnome, Qt, ...), that audo apps do not need in fact but need lot of ressource. Using MSEgui (with pre-created forms) or fpGUI will give access to light machine to multi-track-playing-recording. 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 Friday 28 July 2017 13:20:07 Fred van Stappen wrote: > >> Not easy, it needs the MSE-infrastructure. > > > > Been there, gave up. :) :) :) > > Hello Martin. > > So, it would not be possible to create a console application using MSE > MSE-infrastructure ? > Sure it is possible. Examples are here: https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui 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...
On 28.07.2017 13:20, Fred van Stappen wrote: >> Not easy, it needs the MSE-infrastructure. > Been there, gave up. :) :) :) Hello Martin. So, it would not be possible to create a console application using MSE MSE-infrastructure ? Other than with Lazarus, AFAIK, mse allows for full blown "applications" (with an event queue infrastructure to allow for event driven programming including using TTimer and TThread.Queue / TThread.Synchronize without manually calling checksynchronize) with no GUI binding, hence a "console application" or daemon. -Michael -- 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...
Anyway, I misread the post by Martin you replied to. He said ".. wait *on* main thread... " and not ".. wait *in* main thread... " So the queue is irrelevant on that behalf and you can use a semaphore or e.g. do a poll-loop that includes sleep(). -Michael -- 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 Friday 28 July 2017 12:27:18 Fred van Stappen wrote: > > Huh, I did try this before to post. The problem does not come from any > synchro from audio-thread to graphic-mse main thread. > > The problem comes when a form is created-freed (for example after execute a > dialog-form). Like you said in previous topic, it is the operating system > that think that the audio stream is less important than the main thread. > > So, what I did, is a custom file-dialog that is created at initialisation > of program and activated-hided (not free) when needed. Free is done with > application.terminate. > That way, the audio-thread stay in peace. > What do you think of that way ? > Why not? :-) I could not reproduce the problem with "strumpract" on Linux. 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] Exception handling in MSElang
On Friday 28 July 2017 13:35:37 Graeme Geldenhuys wrote: > On 2017-07-27 17:53, Martin Schreiber wrote: > > I think a > > programming language should represent the actual exception structure. > > The concept I described is supported in Java and works very well there. > So I can't see why it wouldn't for Object Pascal or MSELang. > Do you see in Java the nested kind of operation of the exception handling code or do you need to read the manual? ;-) The overhead is not so big I think. " try // something here except // in case an exception occurs finally // clean-up code here end; " versus " try try // something here except // in case an exception occurs end; finally // clean-up code here end; " 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] Exception handling in MSElang
On 2017-07-27 17:53, Martin Schreiber wrote: I think a programming language should represent the actual exception structure. The concept I described is supported in Java and works very well there. So I can't see why it wouldn't for Object Pascal or MSELang. Anyway, just a suggestion. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- 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...
>> Not easy, it needs the MSE-infrastructure. > Been there, gave up. :) :) :) Hello Martin. So, it would not be possible to create a console application using MSE MSE-infrastructure ? (If yes, it is possible, the MSE console template you give in MSEide does not use MSE-infrastructure, maybe a template with console using MSE would be welcome.) 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...
>> Do you wait on the main thread in worker thread in some way or another? >> Huh, maybe... (but could you give some code of what you propose so I can >> check it ?) > MHO, "waiting" in the main thread is "forbidden". > So the Audio Thread should post an event (I in Delphi and Lazarus use > TThread.Queue for such) and the main thread should react in the event > handler. > E.g. do a property "On" in your outer class, if is not > handled completely in the outer class itself, but the user of same is to > define the code to be run in Many thanks Michael. Of course uos (the audio thread) uses TThread.Queue to post events for main thread. But this is not the problem here, synchro works perfectly (even if the audio thread ask complicated graphic things to do to main thread). The problem comes when a form is created or freed while the audio is playing. In Linux, it pauses the audio-thread for a short moment. 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...
> >> Is it possible to let the audio-thread totally independent ? > > > > Do you wait on the main thread in worker thread in some way or another? > > Huh, maybe... (but could you give some code of what you propose so I can > check it ?) > >> Remove the code snippets which contact the main thread while playing with >>> synchronize() or application.lock()/unlock() for a test. Huh, I did try this before to post. The problem does not come from any synchro from audio-thread to graphic-mse main thread. The problem comes when a form is created-freed (for example after execute a dialog-form). Like you said in previous topic, it is the operating system that think that the audio stream is less important than the main thread. So, what I did, is a custom file-dialog that is created at initialisation of program and activated-hided (not free) when needed. Free is done with application.terminate. That way, the audio-thread stay in peace. What do you think of that way ? And for making docking-floating forms, there will be a filter: ---> if some audio is playing or recording ---> disable the possibility to dock-float forms. (huh, does it exist a property like mseform.dockable/floatable := false ?) > use application.postevent() or tmsecomponent.asyncevent() or > tmsecomponent.postcomponentevent() > instead of application.lock()/unlock(), this is probably more appropriate for > your application anyway. Yep, thanks for the tip, I will use it also. 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...
On 27.07.2017 22:23, Fred van Stappen wrote: > Do you wait on the main thread in worker thread in some way or another? Huh, maybe... (but could you give some code of what you propose so I can check it ?) IMHO, "waiting" in the main thread is "forbidden". So the Audio Thread should post an event (I in Delphi and Lazarus use TThread.Queue for such) and the main thread should react in the event handler. E.g. do a property "On" in your outer class, if is not handled completely in the outer class itself, but the user of same is to define the code to be run in the action). -Michael -- 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 16.07.2017 07:32, Martin Schreiber wrote: TMSEthread.Queue > ? application.postevent(). Often application.lock()/unlock() is more convenient. This is a decent way in the mse-world, as here you supposedly always have a full blown "application" (even "nonGUI"), while in Lazarus only a GUI application features a queue that can handle events, while non-LCL enabled (or "non-GUI") programs can use TThread, but not TApplication. Nonetheless, there, you still can use TThread.Queue (and TThread.Synchronize) if you implement the fetch from the queue yourself by "checksynchronize()", as the queue for TThread.Queue and TThread.Synchronize itself is implemented in the fpc RTL and does not need the LCL. This said, IMHO, providing TMSEthread.Queue does seem appropriate. -Michael -- 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 16.07.2017 07:32, Martin Schreiber wrote: Not easy, it needs the MSE-infrastructure. Been there, gave up. :) :) :) -Michael -- 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
