> >> 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
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
>> 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
>
>> 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
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.
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
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
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
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
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
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,
> 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
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
> 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
> 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
>> 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
> 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
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
> 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
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
20 matches
Mail list logo
