Re: [PD] mtx_./ mtx_*
thanks, works fine ! > Le 12 oct. 2018 à 23:06, Marco Hugo Schretter a écrit : > > dear jean-marie, > > which operating system are you using? > > eg. in my osx pd-extended backups i see that mtx_./ and sometimes > mtx_* is missing. > > if you are on osx and you have a running mtx_* or ./ external you > can try this for testing: > > a) try to call the object using [iemmatrix/mtx_*] instead of [mtx_*] > > if object won't show up then do (i checked it with mtx_bessel) > > b) in your (working) pd-ext 42-5 go to the pd-extended help-browser > -> libraries and look for iemmatrix. now hold down your cmd-key on > the keyboard and doubleclick on iemmatrix in the helpbrowser to see > where it is stored on the harddisk. look for your desired object-help.pd > and it's corresponding .pd_darwin file (i tried mtx_bessel-help.pd + > mtx_bessel.pd_darwin) > > a) then open up your pd ext 43-4 and do the same thing to see the > iemmatrix folder in the finder. there you won't find the helpfile and > the .pd_darwin file, so copy/paste both from the 42-5-iemmatrix-folder. > > restart pd ext 43-4. go to the helpbrowser and check if the new object > is there now. or make a new file and call it with [iemmatrix/mtx_bessel] > > this workaround should work. on linux/windows it's quite the same > procedure. > > the cleaner thing would be to install pd-0.48 with all desired libs from > deken. > > liebe grüße > marco > > > > Am 12.10.18 um 21:09 schrieb Jean-Marie Adrien: >> Hello >> Trying to reopen an old patch with pd-extended, and erased the corresponding >> pd-preferences by mistake ! >> Did everything again in the path prefs at startup, and one function is still >> not found : >> it is mtx_./, and mix*, arithmetic multiplications and divisions of >> matrices, belonging inside a very useful fir_mean_n filter. >> Actually both iemmatrix libraries and iem_matrix are in the paths >> Does anyone knows where this objects are ? guess an iem library ?? >> (actually this object can open it with pd extended 42-5 but not with pd >> extended 43-4, the latter being the version i currently used to open it, so >> i am trying to unscrew the prefs and any hint about the source library is >> worthy in this process…). >> Tks ! >> JM >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] save state. race condition?
Apologies for hijacking this thread, but here's another idea that might simplify the initialization problem. Suppose that [savestate] could take any arguments and then output them as a list when the object is loaded but its contents are empty. So for instance [savestate 1 2] would output "1 2" when it is loaded, unless it has some other contents to output. That way, you could specify a default setting for the abstraction without having to use [loadbang], as in Miller's patch. From: Pd-list on behalf of Liam Goodacre Sent: 13 October 2018 09:07 To: pd-list@lists.iem.at Subject: Re: [PD] save state. race condition? Since you mentioned that [savestate] fires before [loadbang], I tested it and it seems that it functions as a solution for [initbang] also (great!). Ie. if you use [savestate] to dynamically create an inlet inside the abstraction, the connection will not be broken if you save and re-open the parent patch. Should this be documented also? From: Pd-list on behalf of Miller Puckette Sent: 12 October 2018 16:58 To: Atte Cc: pd-list@lists.iem.at Subject: Re: [PD] save state. race condition? One thing that's potentially troublesome is combining savestate and loadbang (and loadbang-like behavior built into GUIs as well.) The savestate output arrives before any loadbangs. So there's extra work to do if you want an object to initialize itself but also to use savestate. Here's an example: #N canvas 29 70 469 394 16; #X floatatom 103 123 7 0 0 1 high - -; #X obj 24 313 outlet~; #X obj 103 5 loadbang; #X obj 24 48 inlet~; #X floatatom 103 146 7 0 0 1 low - -; #X msg 103 67 1; #X obj 25 275 clip~; #X obj 375 209 f; #X obj 375 238 pack; #X obj 288 145 savestate; #X obj 288 249 unpack; #X obj 103 34 spigot 1; #X msg 194 34 0; #X connect 0 0 6 2; #X connect 0 0 7 1; #X connect 2 0 11 0; #X connect 3 0 6 0; #X connect 4 0 6 1; #X connect 4 0 8 1; #X connect 5 0 0 0; #X connect 6 0 1 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 10 0; #X connect 9 0 12 0; #X connect 9 1 7 0; #X connect 10 0 0 0; #X connect 10 1 4 0; #X connect 11 0 5 0; #X connect 12 0 11 1; #X coords 0 -1 1 1 130 70 1 100 100; I badly need to update the documentation with better examples of how to use feaures like this... cheers Miller On Fri, Oct 12, 2018 at 04:56:39PM +0200, Atte via Pd-list wrote: > Hi > > I just simply flat out love the new savestate mechanism! > > I normally start from the example in the help, add sends/receives, I use it > alot with number boxes and toggles. > > I found that in larger patches, sometimes the states doesn't always "get to" > all receives, the gui elements seems to always work, but if I use a restored > value, I need to add a [pipe 0.0001] after the [r $0-somevalue] and where I > want to use it. > > I tried comming up with a simple example that shows this behavious, but it > needs a patch of a certain complexity, so I'll have to continue on the > bug-example. > > Anyone one else been bitten by this? Any tips on avoiding it? > > If it matters I'm on linux, pd version "0.49.0-2~bpo9+1" from debian > backports... > > Cheers > -- > Atte > > http://atte.dk http://a773.dk > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] save state. race condition?
Since you mentioned that [savestate] fires before [loadbang], I tested it and it seems that it functions as a solution for [initbang] also (great!). Ie. if you use [savestate] to dynamically create an inlet inside the abstraction, the connection will not be broken if you save and re-open the parent patch. Should this be documented also? From: Pd-list on behalf of Miller Puckette Sent: 12 October 2018 16:58 To: Atte Cc: pd-list@lists.iem.at Subject: Re: [PD] save state. race condition? One thing that's potentially troublesome is combining savestate and loadbang (and loadbang-like behavior built into GUIs as well.) The savestate output arrives before any loadbangs. So there's extra work to do if you want an object to initialize itself but also to use savestate. Here's an example: #N canvas 29 70 469 394 16; #X floatatom 103 123 7 0 0 1 high - -; #X obj 24 313 outlet~; #X obj 103 5 loadbang; #X obj 24 48 inlet~; #X floatatom 103 146 7 0 0 1 low - -; #X msg 103 67 1; #X obj 25 275 clip~; #X obj 375 209 f; #X obj 375 238 pack; #X obj 288 145 savestate; #X obj 288 249 unpack; #X obj 103 34 spigot 1; #X msg 194 34 0; #X connect 0 0 6 2; #X connect 0 0 7 1; #X connect 2 0 11 0; #X connect 3 0 6 0; #X connect 4 0 6 1; #X connect 4 0 8 1; #X connect 5 0 0 0; #X connect 6 0 1 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 10 0; #X connect 9 0 12 0; #X connect 9 1 7 0; #X connect 10 0 0 0; #X connect 10 1 4 0; #X connect 11 0 5 0; #X connect 12 0 11 1; #X coords 0 -1 1 1 130 70 1 100 100; I badly need to update the documentation with better examples of how to use feaures like this... cheers Miller On Fri, Oct 12, 2018 at 04:56:39PM +0200, Atte via Pd-list wrote: > Hi > > I just simply flat out love the new savestate mechanism! > > I normally start from the example in the help, add sends/receives, I use it > alot with number boxes and toggles. > > I found that in larger patches, sometimes the states doesn't always "get to" > all receives, the gui elements seems to always work, but if I use a restored > value, I need to add a [pipe 0.0001] after the [r $0-somevalue] and where I > want to use it. > > I tried comming up with a simple example that shows this behavious, but it > needs a patch of a certain complexity, so I'll have to continue on the > bug-example. > > Anyone one else been bitten by this? Any tips on avoiding it? > > If it matters I'm on linux, pd version "0.49.0-2~bpo9+1" from debian > backports... > > Cheers > -- > Atte > > http://atte.dk http://a773.dk > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] performance of burried gui-elements
i always assumed so yes. the “not shown on screen” part might change that though. > On 13 Oct 2018, at 09:02, Atte via Pd-list wrote: > > Quick question: > Does a [bng] in an abstraction (not shown on screen) cost more than |bang(? > Same for number atoms over [f ]? > > Cheers > -- > Atte > > http://atte.dk http://a773.dk > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
