Re: [MSEide-MSEgui-talk] Some question about MSE thread...

[Fred van Stappen]

>> 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 thread.

And then Martin shows me that... TThread.priority was not implemented. ;-(

After this, I did check the fpc docu and it is never said that is not 
implemented.
I was feeling this as unfair.
https://www.freepascal.org/docs-html/rtl/classes/tthread.priority.html

Fre;D
TThread.Priority - Free 
Pascal
www.freepascal.org
TThread.Priority. Returns the thread priority. Declaration. Source position: 
classesh.inc line 1713




--
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...

[Graeme Geldenhuys]

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 the lesser of two evils.


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...

[Graeme Geldenhuys]

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 - I guess it's an kernel 
API thing.


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...

[Fred van Stappen]

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] 
/// ---> delete that line or set to default.
...

--> no more crash for mseide, main.pas can be viewed as form.

OK, now I can work on main.pas with msedesigner.

Compile is ok but when running --> crash.

To solve this, with Object Inspector, select tlayouter1.optionsscale = 
[lao_placex,lao_aligny] and set all to default:

optionsscale = []

Now after compiling, noisegen runs (see attachment).

So, to resume, on my Linux 64 Mint system there is problem with:

tlayouter.optionsscale = [osc_expandy, osc_shrinky, osc_expandshrinkx, 
osc_expandshrinky] --> crash mseide when show as form.

tlayouter.optionslayout = [lao_placex,lao_aligny] --> crash the compiled 
executable.

And, the fast way, if deleting those 2 lines in last main.mfm (= setting to 
default), all is working like charms on my system.

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...

[Fred van Stappen]

> 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, 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...

[Fred van Stappen]

> 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 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...

[Fred van Stappen]

> 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 your new code.

You added a average: tbooleanedit  and averagecount: tintegerdisp + 2 layouters.


To get it work (I know it is not the academic way), using the previous 
main.mfm, open main.pas with mse designer, add a average: tbooleanedit  and 
averagecount: tintegerdisp.


Assign averagesetev to average.onsetvalue + buffullev to 
fft.sampler.onbufferfull.


Then in main.pas, delete those 2 added objects in tmainfo = class(tmainform) 
because there are twice declared.


I will investigate more tonight but I suspect the 2 tlayouter to be part of the 
problem.


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...

[Martin Schreiber]

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 mseuniverse.zip from git.
>
> 2) - Load noisegen.prj with official MSEide.
With that I mean MSEide current git master version 
(11e5692ad84ec11599f509a6fc69cb058d605dec or newer).
>
> 3) - Open main.pas from official MSEide menu Files/Open.
>
I get the attached screenshot. And now?
At other MSEgui users: please, can you reproduce the problem?

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...

[Fred van Stappen]

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)

3) - Load noisegen.prj with official MSEide.

4) - Open main.pas from official MSEide menu Files/Open.

5) - Compile and run it.

Fre;D




main_mfm_good.tar.bz2
Description: main_mfm_good.tar.bz2


main_mfm_bad.tar.bz2
Description: main_mfm_bad.tar.bz2
--
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...

[Fred van Stappen]

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.

I do not know if main.mfm is sequential but it solves all.

>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.

I have to check this, I cannot do it here, write you later.

> operating system, which window manager?

Linux Mint 64 bit with Mint-built in WM

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...

[Martin Schreiber]

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 (recompiled with last msegui) crash when trying to show
> main.pas as form.
>
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 
operating system, which window manager?

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...

[Martin Schreiber]

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:
>- main.mfm
>- main_mfm.pas
>
> 2) Paste (and overwrite) those files into last mseuniverse-noisegen
> directory (but keeping last main.pas untouched).
>
> 3) Load noisegen.prj with last mseide.
>
> 4) Do "show as form" main.pas ---> perfect, no crash.
>
> 5) Compile noisegen.pas with last msegui --> ok, it compiles.
>
> 6) Run noisegen ---> yep, I get-hear the colored noises perfectly.
>
> So, IMHO, my conclusions are: main.mfm or/and main_mfm.pas are corrupt in
> last commit.
>
They work for me (a161c60933f3b4b3165044ce8e5237b33a088554).

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...

[Martin Schreiber]

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 (recompiled with last msegui) crash when trying to show
> main.pas as form.
>
> See previous attachment.
>
But this is not the original MSEide?

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...

[Fred van Stappen]

> 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 mseuniverse-noisegen directory 
(but keeping last main.pas untouched).

3) Load noisegen.prj with last mseide.

4) Do "show as form" main.pas ---> perfect, no crash.

5) Compile noisegen.pas with last msegui --> ok, it compiles.

6) Run noisegen ---> yep, I get-hear the colored noises perfectly.

So, IMHO, my conclusions are: main.mfm or/and main_mfm.pas are corrupt in last 
commit.

Huh, in previous mail I sent a attachment of working old main.mfm + 
main_mfm.pas but I receive a Outlook warning that the message could not be 
sent...

So, you may try with a earlier commit of  main.mfm + main_mfm.pas .

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...

[Michael Schnell]

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
--
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...

[Martin Schreiber]

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 different computers with 32 bit and 64 bit Linux. I don't 
know where to dig.

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...

[Martin Schreiber]

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: Identifier not found "sso_average"
> main.pas(77,48) Error: Identifier not found "sso_average"
> main.pas(84,9) Error: identifier idents no member "lockapplication"
> main.pas(84,25) Error: Illegal expression
> main.pas(84,26) Fatal: Syntax error, ")" expected but ";" found
>
Current MSEgui git master version is necessary for the noisegen demo because 
of the new fft-average functionality.

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...

[Martin Schreiber]

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

--
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...

[Fred van Stappen]

> 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.

See previous attachment.

PS: If it can help, earlier commit of mseuniverse and msegui, after deleting 
macros in noisegen.prj, compiles and run perfectly.
The white, pink and brown noises where produced perfectly (**very impressive**).

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...

[Fred van Stappen]

> 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...).

Thanks.

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...

[Fred van Stappen]

> 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, 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...

[Martin Schreiber]

>
> 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.

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...

[Fred van Stappen]

> 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 TThread.Priority if not implemented ?

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...

[Fred van Stappen]

> 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 if PulseAudio or a 
other audio port wrapper is not installed.  But, I agree Pulse is good too but 
needs lot of dependencies to install. Stop no propaganda here.)

Anyway, your MSEsignal is **very** impressive (and would be very welcome in the 
uos Synthesizer section (that can generate, for the moment, only simple sine 
waves) :-)).

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).

Many thanks and wow Martin.

PS: You are unmasked --> you are a Audio-Guru too ;-)

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...

[Fred van Stappen]

>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, you propose to use, as unique thread, the thread created 
by the portaudio library ?

If so, hum, yes it is possible but I will loose full control over the 
C-portaudio-thread (for example for pausing with RTL event), and only have the 
methods that portaudio gives to deal with the thread.

Anyway, your discovery of a hidden thread gives lot of new perspectives and a 
big space for new experiments.

And to re-think all uos.

Thanks for that.

Fre;D





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
--
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...

[Martin Schreiber]

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 "nice"-value per thread which 
probably could be used.

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...

[Martin Schreiber]

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, sorry.

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...

[Fred van Stappen]

  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, 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...

[Fred van Stappen]

> 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
  {$Warning ThreadSetPriority needs to be implemented}
  result:=false;
end;


  function  CThreadGetPriority (threadHandle : TThreadID): Integer;
begin
  {$Warning ThreadGetPriority needs to be implemented}
  result:=0;
end;


Houlala, and I who had said that tpTimeCritical has a **huge** impact on the 
number of synchronized input...
I feel completely stupid now.

Please, Martin, give us MSElang, I am tired of the fpc lies.

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...

[Fred van Stappen]

> 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 Linux, if pulseaudio is 
installed.


So I am **very** disappointed with your discover (many, many thanks to show 
this).


OK, time to annoy people in PortAudio forum (but difficult, they never answer).

> BTW, do you know MSEsignal? I made a small example:
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/signal/keyboard

Ha, good meat for this week-end, I do not know MSEsignal, will jump into it.

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...

[Martin Schreiber]

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 closing-free dialog forms.
rtl/unix/cthreads.pp:
"
function  CThreadSetPriority (threadHandle : TThreadID; Prio: longint): 
boolean; {-15..+15, 0=normal}
begin
  {$Warning ThreadSetPriority needs to be implemented}
  result:=false;
end;


  function  CThreadGetPriority (threadHandle : TThreadID): Integer;
begin
  {$Warning ThreadGetPriority needs to be implemented}
  result:=0;
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] Some question about MSE thread...

[Fred van Stappen]

>> 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...

[Fred van Stappen]

> 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...

[Fred van Stappen]

> 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...

[Fred van Stappen]

> 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...

[Martin Schreiber]

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...

[Martin Schreiber]

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...

[Fred van Stappen]

> 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...

[Fred van Stappen]

> 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...

[Martin Schreiber]

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...

[Michael Schnell]

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...

[Michael Schnell]

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...

[Martin Schreiber]

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] Some question about MSE thread...

[Fred van Stappen]

>> 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...

[Fred van Stappen]

>> 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...

[Fred van Stappen]

> >> 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...

[Michael Schnell]

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...

[Michael Schnell]

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...

[Michael Schnell]

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

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

[Martin Schreiber]

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 ?)
>
Remove the code snippets which contact the main thread while playing with 
synchronize() or application.lock()/unlock() for a test.
If that is the problem use application.postevent() or 
tmsecomponent.asyncevent() or tmsecomponent.postcomponentevent() instead of 
application.lock()/unlock(), this is probably more appropriate for your 
application anyway.

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...

[Fred van Stappen]

>> 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 important to do  
> than running the worker thread.

Aaaargh, same problem than with LCL GTK2 ( fpGUI does not have that prob).

Thanks.

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...

[Martin Schreiber]

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.
>
>
> I did try using a mse thread or a fpc-tthread but the result is the same :
> a short pause in the song playing when closing the file-dialog.
>
>
> 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? If not 
the operating system probably thinks there is something more important to do 
than running the worker 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...

[Fred van Stappen]

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 same : a 
short pause in the song playing when closing the file-dialog.


Is it possible to let the audio-thread totally independent ?


Thanks.


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...

[Fred van Stappen]

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".

https://github.com/fredvs/uos

Commit: 3acd6e3..ea3fc37

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...

[Martin Schreiber]

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 https://github.com/fredvs/strumpract and I am sure that the
> leaks do not com from uos) :
> 
Compiled with -ghl -O- -B the Output is
"
...
Call trace for block $77FEF860 size 144
  $006A19DD line 2054 of uos_flat.pas
  $004631FE line 670 of main.pas
  $00465742 line 1107 of main.pas
  $00667D7A line 1011 of
../../../mseide-msegui/lib/common/widgets/mseforms.pas
  $0066811A line 1103 of
../../../mseide-msegui/lib/common/widgets/mseforms.pas
  $004A182A line 6753 of
../../../mseide-msegui/lib/common/fpccompatibility/mclasses.pas
  $004FD102 line 2269 of
../../../mseide-msegui/lib/common/kernel/mseclasses.pas
...
"
uos_flat.pas:2054 is
"
   uosPlayers[PlayerIndex] := Tuos_Player.Create();
"
-> uosPlayers[] are not freed.
"

It works for me with
"
diff --git a/src/uos_flat.pas b/src/uos_flat.pas
index 18d0860..c73cd7b 100644
--- a/src/uos_flat.pas
+++ b/src/uos_flat.pas
@@ -1794,7 +1794,9 @@ begin
begin
 uosPlayers[PlayerIndex].Stop() ;
 {$IF DEFINED(mse)}
-  uosPlayers[PlayerIndex] := nil;
+//  uosPlayers[PlayerIndex] := nil;
+  freeandnil(uosPlayers[PlayerIndex]);
+
   uosPlayersStat[PlayerIndex] := -1 ;
  {$endif}
 end;
"

"
diff --git a/src/uos.pas b/src/uos.pas
index 03d08d7..0699c54 100644
--- a/src/uos.pas
+++ b/src/uos.pas
@@ -7844,8 +7844,8 @@ begin
  {$endif}

  {$IF DEFINED(mse)}
- thethread.terminate();
- freeandnil(self);
+// thethread.terminate();
+// freeandnil(self); //the instance is still in use!
   {$else}
   FreeOnTerminate:=True;
   terminate();
@@ -8424,7 +8424,14 @@ destructor Tuos_Player.Destroy;
 var
   x: cint32;
 begin
-
+ {$ifdef mse}
+  if thethread <> nil then begin
+   thethread.terminate();
+   application.waitforthread(thethread);
+//calls unlockall()/relockall in order to avoid possible deadlock
+   thethread.destroy();
+  end;
+ {$endif}
   if assigned(evPause) then RTLeventdestroy(evPause);

   if length(StreamOut) > 0 then
"

--
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...

[Fred van Stappen]

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 https://github.com/fredvs/uos

Many thanks for your vision.

Other thing.

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 https://github.com/fredvs/strumpract and I am 
sure that the leaks do not com from uos) :

12214 memory blocks allocated : 3509235/3545088
12194 memory blocks freed : 3481899/3517752
20 unfreed memory blocks : 27336
True heap size : 1867776
True free heap : 1837216
Should be : 1837880
Call trace for block $77EDAC40 size 160
Call trace for block $77EDAB00 size 160
Call trace for block $77EDA9C0 size 160
Call trace for block $77EDA880 size 160
Call trace for block $77EDA740 size 160
Call trace for block $77EDA600 size 160
Call trace for block $77EDA4C0 size 160
Call trace for block $77EDA380 size 160
  $00497C9B line 6525 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $00497029 line 6249 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
Call trace for block $74533AB0 size 4112
Call trace for block $77EB21C0 size 392
Call trace for block $77E62F80 size 24
Call trace for block $745329F0 size 4112
Call trace for block $77EC34C0 size 352
Call trace for block $74531930 size 4112
Call trace for block $77EC32C0 size 352
Call trace for block $77E70440 size 32
  $004986B9 line 6685 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $00497C9B line 6525 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $00497029 line 6249 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $004970EC line 6262 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
Call trace for block $77FE46C0 size 96
Call trace for block $77F86740 size 144
Call trace for block $77E23170 size 12288
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
  $F0F0F0F0F0F0F0F0
Call trace for block $77E70380 size 40
  $004986B9 line 6685 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $00497C9B line 6525 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $00497029 line 6249 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas
  $004970EC line 6262 of 
../../msegui/lib/common/fpccompatibility/mclasses.pas

Thanks.

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...

[Martin Schreiber]

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 part of the class vs a custom thread with all  the objects
> part of the thread ?
>
No need of a custom thread. ;-)
The idea is that the custom class implements the whole functionality and can 
inherit from any class you want, it must not necessarily be a tmsethread. The 
thread itself is a standard sub-object like a stream or a list.

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...

[Martin Schreiber]

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 creator of the thread ?
>
It can if you like the idea of the thread(s) as standard sub-object(s) of a 
sound class. But doing it in FPC-way as tmsethread descendant is OK too.

> But, would it not be faster to create the thread paused before and at
> os_play() only resume the thread (like uos does) ?
>
If that time matters waiting on a semaphore in the worker thread probably 
provides the least delay, yes.

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...

[Fred van Stappen]

>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 paused before and at os_play() 
only resume the thread (like uos does) ?

Thanks.

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...

[Fred van Stappen]

>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 thread ?

Of course I see the fact that when creating the thread all can be done before 
but why is it so much better ?

IMHO (maybe stupid) I was thinking that if all the objects are part of the 
thread, all the thread is more independent.

Thanks.

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...

[Fred van Stappen]

>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 Tuos_Player ? --->

 StreamIn: array of Tuos_InStream;
 StreamOut: array of Tuos_OutStream;
 PlugIn: array of Tuos_Plugin;

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...

[Martin Schreiber]

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 environment.

An example is here:
https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/classwiththread

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...

[Martin Schreiber]

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

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

[Fred van Stappen]

> > > 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...

[Fred van Stappen]

> 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...

[Fred van Stappen]

> 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...

[Martin Schreiber]

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...

[Fred van Stappen]

> 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...

[Fred van Stappen]

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
--
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...

[Fred van Stappen]

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 has to override it to use it.

Here what I did for mse:

Tmymsethread = class(tmsethread)
ExecuteLoop: threadprocty;
hasstarted: boolean ;
procedure start;
constructor create(const athreadproc: threadprocty;
const afreeonterminate: boolean = false;
const astacksizekb: integer = 0);
end;


constructor Tmymsethread.create(const athreadproc: threadprocty;
const afreeonterminate: boolean = false;
const astacksizekb: integer = 0);
   begin
   hasstarted := false;
   inherited Create(executeloop, true, astacksizekb);
   end;

// The Main Loop Procedure
function Tmymsethread.ExecuteLoop : threadprocty;
begin
while hasstarted = false do sleep(10); // this because there is no 
CreateSuspended mse parameter.

while // here the big loop
...
end;

// to start the big loop:
procedure start;
begin
hasstarted := true;
end;

But after start, nothing appends.

Other thing.
I use RTLEvent for pausing threads.
Does msethreads accept it ?

Thanks.

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...

[Fred van Stappen]

Hello Martin.


Wow.


OK, I will add a new line in define.inc of uos -->


{.$DEFINE mse}   // when using a mse project uncomment for building using mse 
thread and timer


... and adapt uos code for that new define.


Write you later.


Fre;D


De : Martin 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 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) >  TMSEthread = class(tthreadcomp) > ok
> ?
>
tthreadcomp is a container of teventthread which can be placed in a form.
In order to replace a FPC TThread one probably would use tmsethread or one of
its descendants (tmutexthread -> tsemthread -> teventthread). tmutexthread
has a mutex, tsemthread a semaphore and teventthread an event queue.

> constructor TMSEthread.Create(CreateSuspended: boolean;
>   const StackSize: SizeUInt) > ?
>
   constructor create(const athreadproc: threadprocty;
const afreeonterminate: boolean = false;
const astacksizekb: integer = 0); overload; virtual;

> destructor Destroy; override > ?
>
   destructor destroy; override;

> procedure Execute; override > ?
>
   function execute(thread: tmsethread): integer; virtual;

> procedure DoTerminate; override > ?
>
Does not exist, there is tthreadcomp.onterminate and tthreadcomp.onterminated.
> ...
>
> TMSEthread.Start > ?
>
tmsethread starts automatically, there is tthreadcomp.active.

> TMSEthread.Queue > ?
>
application.postevent(). Often application.lock()/unlock() is more convenient.

> TMSEthread.FreeOnTerminate := true > ?
>
tmsethread.freeonterminate:= true;

> TMSEthread.Priority := tpTimeCritical > ?

Not implemented.

> ...
>
> About using MSEThreads outside a MSE project...
> Is it possible?

Not easy, it needs the MSE-infrastructure.

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk



--
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...

[Martin Schreiber]

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) >  TMSEthread = class(tthreadcomp) > ok
> ?
>
tthreadcomp is a container of teventthread which can be placed in a form.
In order to replace a FPC TThread one probably would use tmsethread or one of 
its descendants (tmutexthread -> tsemthread -> teventthread). tmutexthread 
has a mutex, tsemthread a semaphore and teventthread an event queue.

> constructor TMSEthread.Create(CreateSuspended: boolean;
>   const StackSize: SizeUInt) > ?
>
   constructor create(const athreadproc: threadprocty;
const afreeonterminate: boolean = false;
const astacksizekb: integer = 0); overload; virtual;

> destructor Destroy; override > ?
>
   destructor destroy; override;

> procedure Execute; override > ?
>
   function execute(thread: tmsethread): integer; virtual;

> procedure DoTerminate; override > ?
>
Does not exist, there is tthreadcomp.onterminate and tthreadcomp.onterminated.
> ...
>
> TMSEthread.Start > ?
>
tmsethread starts automatically, there is tthreadcomp.active.

> TMSEthread.Queue > ?
>
application.postevent(). Often application.lock()/unlock() is more convenient.

> TMSEthread.FreeOnTerminate := true > ?
>
tmsethread.freeonterminate:= true;

> TMSEthread.Priority := tpTimeCritical > ?

Not implemented.

> ...
>
> About using MSEThreads outside a MSE project...
> Is it possible?

Not easy, it needs the MSE-infrastructure.

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