>> Yes but why publish TThread.Priority if not implemented ?
> Not ideal - I know, but it is the lesser of two evils.
Huh, in fact I was in bad mood.
I affirmed loud in MSE forum that with fpc TThread and priority set to
tpTimeCritica, I could synchronize much more inputs with uos in a single
On 2017-07-29 22:15, Fred van Stappen wrote:
Yes but why publish TThread.Priority if not implemented ?
It's a not so often used feature, and it is better to have Priority
published thus more cross-platfrom without end-users programs requiring
IFDEF statements. Not ideal - I know, but it is
On 2017-07-29 14:28, Fred van Stappen wrote:
{$Warning ThreadSetPriority needs to be implemented}
Just so you know Fred, it was the same with Borland Kylix - at first.
Later it was changed (I think), but you could only set and get thread
priority with root access. FPC follows the same
Hello Martin.
Some news from the front.
There is something wrong with tlayouter on my system.
If, in main.mfm, with a text editor, you delete or set to default that line:
object tlayouter1: tlayouter
...
optionsscale = [osc_expandy, osc_shrinky, osc_expandshrinkx, osc_expandshrinky]
/// --->
> And now?
Sometime video speaks better than words:
https://sites.google.com/site/fredvsbinaries/noisegen_crash.mp4
Fre;D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
> With that I mean MSEide current git master version
> (11e5692ad84ec11599f509a6fc69cb058d605dec or newer).
Yes, I use this one.
Fre;D
--
Check out the vibrant tech community on one of the world's most
engaging tech
> I get the attached screenshot. And now?
Ooops, I forget to add the last step.
3) - Open main.pas from official MSEide menu Files/Open.
4) - A message will say that a file is missing -> choose
samples/skin/defaultskin.mfm
5) - Do a screen-shot of the crash.
By the way, I did analyse
On Tuesday 01 August 2017 00:52:48 Fred van Stappen wrote:
> > That means main.mfm has been loaded as text? Can you reproduce it again
> > with
> >
> > untouched files from git? If yes, please report the exact steps. Which
>
> Hello Martin.
>
>
> The steps for the crash.
>
> 1) - Unzip
Re-hello Martin.
Huh, after check, I need to replace also previous main_mfm.pas.
Otherwise noisegen crash at run.
So the steps for the solution.
1) - Unzip mseuniverse.zip from git.
2) - Replace /noisegen/main.mfm and main_mfm.pas with previous main.mfm
and main_mfm.pas (see attachment)
Hello Martin.
I found a guilty for my system: tsplitter1.
object tsplitter1: tsplitter
...
linkleft = scope
linkright = fft
...
end
In new main.mfm tsplitter1 is placed before object scope and fft.
I did move in code object tsplitter1 after object scope/fft and all comes ok.
On Monday 31 July 2017 00:38:13 Fred van Stappen wrote:
> > Maybe all will be ok, so sorry for the noise. (no web connexion in 3
> > minutes...).
>
> Just tested with last msegui + recompiled mseide.
>
>
> noisegen.prj compiles ok but crash at run.
>
> See attachment.
>
> Also last mseide
On Monday 31 July 2017 16:55:59 Fred van Stappen wrote:
> > Works for me on two different computers with 32 bit and 64 bit Linux. I
> > don't know where to dig.
>
> Hello Martin.
>
> Sorry, I never give up.
>
Me neither. ;-)
> What I did:
>
> 1) Copy from a earlier working mseuniverse-noisegen:
>
On Monday 31 July 2017 00:38:13 Fred van Stappen wrote:
> > Maybe all will be ok, so sorry for the noise. (no web connexion in 3
> > minutes...).
>
> Just tested with last msegui + recompiled mseide.
>
>
> noisegen.prj compiles ok but crash at run.
>
> See attachment.
>
> Also last mseide
> Works for me on two different computers with 32 bit and 64 bit Linux. I don't
> know where to dig.
Hello Martin.
Sorry, I never give up.
What I did:
1) Copy from a earlier working mseuniverse-noisegen:
- main.mfm
- main_mfm.pas
2) Paste (and overwrite) those files into last
On 28.07.2017 19:51, Fred van Stappen wrote:
Huh, ... , and do you think it could be possible to compile a fpGUI
app with mse console ?
Something similar this is what tried some years ago (with some help
from Martin)ad gave up
-Michael
On Monday 31 July 2017 00:38:13 Fred van Stappen wrote:
> > Maybe all will be ok, so sorry for the noise. (no web connexion in 3
> > minutes...).
>
> Just tested with last msegui + recompiled mseide.
>
>
> noisegen.prj compiles ok but crash at run.
>
> See attachment.
>
Works for me on two
On Sunday 30 July 2017 23:24:19 Fred van Stappen wrote:
>The ide crash after loading
> defaultskinmo. See attachment.
>
Can not reproduce. Does it happen in original MSEide too?
> Also there are new error messages (that was not in previous commit):
>
> Compiling main.pas
> main.pas(74,48) Error:
On Sunday 30 July 2017 16:25:00 Fred van Stappen wrote:
> > Please try again with git master
> > ae9819b12f83976252955de4c206cf357682a7c9,
>
> See attachment.
> Where is defaultskinmo ?
>
In ../../skin (samples/skin).
Martin
> Maybe all will be ok, so sorry for the noise. (no web connexion in 3
> minutes...).
Just tested with last msegui + recompiled mseide.
noisegen.prj compiles ok but crash at run.
See attachment.
Also last mseide (recompiled with last msegui) crash when trying to show
main.pas as form.
> Also there are new error messages (that was not in previous commit):
Ooops, I just see that there is a new commit for msegui too.
OK, I update now msegui and will try noisegen.prj with this last commit.
Maybe all will be ok, so sorry for the noise. (no web connexion in 3
minutes...).
> Please try again with git master ae9819b12f83976252955de4c206cf357682a7c9,
See attachment.
Where is defaultskinmo ?
Fre;D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
>
> And the noisegen demo --> **super** WOW. (maybe you should update the
> noisegen.prj, it is unusable with the macros defined now for fpc > 2.6,
> after deleting all the macros, it compiles ok).
>
Please try again with git master ae9819b12f83976252955de4c206cf357682a7c9,
thanks for reporting.
> http://free-pascal-general.1045716.n5.nabble.com/TThread-Priority-when-td57
>29381.html
> As I wrote before, on Linux and FreeBSD a normal user can not change the
> thread priority. On Linux there seems to be a "nice"-value per thread which
> probably could be used.
Yes but why publish
> BTW, do you know MSEsignal? I made a small example:
https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/signal/keyboard
WOW.
Once again, you are Magic Martin.
You choose PulseAudio as audio-port multi-os library.
OK.
(IMHO, PortAudio is more low level, it can work alone even
>Then probably pa_mainloop_run() is in PortAudio? I don't know, sorry.
Yes. Portaudio can deal directly with the audio ports or delegate the work to
the installed audio wrapper.
By default, uos load Portaudio using the the installed audio wrapper (pulse if
installed).
So, if understand ok,
On Saturday 29 July 2017 15:44:53 Fred van Stappen wrote:
> I am bad --->
> http://free-pascal-general.1045716.n5.nabble.com/TThread-Priority-when-td57
>29381.html
>
As I wrote before, on Linux and FreeBSD a normal user can not change the
thread priority. On Linux there seems to be a
On Saturday 29 July 2017 15:20:20 Fred van Stappen wrote:
> > See attachments, for every uos_player thread there is a second i
> > pulseaudio library.
>
> Booom, i am on my ass. ;-(
>
>
> uos do not have access to pulsaudio library.
>
Then probably pa_mainloop_run() is in PortAudio? I don't know,
I am bad --->
http://free-pascal-general.1045716.n5.nabble.com/TThread-Priority-when-td5729381.html
Fre;D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
> For fpc TThread there is property Priority := tpTimeCritical.
>
> But this has no impact on the audio-pause when closing-free dialog forms.
>rtl/unix/cthreads.pp:
"
function CThreadSetPriority (threadHandle : TThreadID; Prio: longint):
boolean; {-15..+15, 0=normal}
begin
> See attachments, for every uos_player thread there is a second i pulseaudio
> library.
Booom, i am on my ass. ;-(
uos do not have access to pulsaudio library.
All the connections to the audio ports are done by PortAudio library.
And PortAudio library does connection to pulseaudio in
On Friday 28 July 2017 20:19:38 Fred van Stappen wrote:
> > 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
>> 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
> 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 this has no impact on the audio-pause when closing-free dialog forms.
But it has a huge impact on the number of input
> 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
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
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
> 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
> 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
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 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
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
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
>> 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
>> 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
>
> >> 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 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 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,
On Thursday 27 July 2017 22:23:25 Fred van Stappen wrote:
> >> 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 ?)
>
>> 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 ?)
> the operating system probably thinks there is something more
On Thursday 27 July 2017 10:17:36 Fred van Stappen wrote:
> Hello Martin.
>
>
> When closing a mse file-dialog, floating window from dock or docking a
> floating widow, this has impact on a independent thread (for example a song
> playing) ---> this pause for a short moment the audio-thread.
>
>
>
Hello Martin.
When closing a mse file-dialog, floating window from dock or docking a floating
widow, this has impact on a independent thread (for example a song playing)
---> this pause for a short moment the audio-thread.
I did try using a mse thread or a fpc-tthread but the result is the
Hello Magic Martin.
13633 memory blocks allocated : 5163889/5199872
13633 memory blocks freed : 5163889/5199872
0 unfreed memory blocks : 0
True heap size : 950272
True free heap : 950272
More than many thanks.
You are added in the list of "Great Contributors of uos".
On 07/19/2017 02:38 AM, Fred van Stappen wrote:
>
> It is about mse and memory leak.
> I do not find how to kill those memory leaks, it seems to me that all
> was freed before to close the mse application but I get this, how can I
> debug that ? (huh, it comes with the
> project
Hello Martin.
OK, your advices are order.
Now uos_Player is a class that has a thread as child.
The conversion was 1,2,3 for msethreads but 1,2,3,4,1,2,3,4,1,2,3,4,... for
TThread (needs parent variable).
But well, the conversion is done and all works as expected.
Commit: 3acd6e3 of
On Tuesday 18 July 2017 14:53:53 Fred van Stappen wrote:
> >An example is here:
> >
> > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/c
> >lasswiththread
>
> Ha, ok, I see.
>
> Hum, what are the advantage to use a custom class with a thread inside and
> all the objects
On Tuesday 18 July 2017 15:15:01 Fred van Stappen wrote:
> >An example is here:
> > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/c
> >lasswiththread
>
> Re-re hello Martin.
>
>
> Aaargh, you make me full of doubt.
>
> If I understand ok, for you, uos_play() must be the
>An example is here:
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/classwiththread
Re-re hello Martin.
Aaargh, you make me full of doubt.
If I understand ok, for you, uos_play() must be the creator of the thread ?
But, would it not be faster to create the thread
>An example is here:
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/classwiththread
Ha, ok, I see.
Hum, what are the advantage to use a custom class with a thread inside and all
the objects part of the class vs
a custom thread with all the objects part of the
>An example is here:
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/classwiththread
Thanks Martin, I will take a look and try to understand what yu want.
Huh, what dont you like with the actual Tuos_Player = class(tmsethread) ?
The fact that this objects are part of
On Tuesday 18 July 2017 06:48:05 Martin Schreiber wrote:
>
> 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
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
> > > 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
> 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
> 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!
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
> 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
Re-hello Martin.
In previous mail, do not take too much attention with:
function Tmymsethread.ExecuteLoop : threadprocty;
It has absolutely no sense, only to show you that I am loosed with the use of
mse main-thread-loop.
Fre;D
Hello Martin.
OK, the conversion (seems) done.
There are no more errors, crashs nor warnings.
But there is no sound too. ;-(
I do not catch what to do with the main-procedure-loop of the mse thread.
With a fpc TThread, the main-procedure-loop is the published "Execute"
procedure.
So the one
tin Schreiber <mse00...@gmail.com>
Envoyé : dimanche 16 juillet 2017 07:32
À : mseide-msegui-talk@lists.sourceforge.net
Objet : Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Sunday 16 July 2017 00:04:48 Fred van Stappen wrote:
> Hello Martin
>
> Some question about MSE th
On Sunday 16 July 2017 00:04:48 Fred van Stappen wrote:
> Hello Martin
>
> Some question about MSE threads (tthreadcomp?)...
>
> Mainly how to convert fpc TThread into mse tthreadcomp...
>
> How do you convert this in mse code (+ some tips are welcome)?
>
>
> TMSEthread = class(TThread) >
72 matches
Mail list logo
