Re: [PD] Experiencing a higher CPU load with 0.47-0 and 0.47-1.
I'm actually sensing something that may be related... when starting pd and a patch, GUI and audio takes a little time to respond, but after things pick up it just seems to carry on fine. I'm on OSX 10.11.3 2016-06-26 8:27 GMT-03:00 Dario Sanfilippo : > Hi, list. > > I'm loading the same patch with 0.46-7, 0.47-0 and 0.47-1 - all 64bit. The > last two have a significantly higher CPU load. I'm on OSX 10.11.5. > > Has any of you experienced anything similar? > > I haven't changed my [vd~] objects into [delread4~], are they calling the > same piece of code? > > The patch is almost exclusively using signal objects, have some of these > been modified in 0.47-0 and 0.47-1? > > Thanks for your help. > > Dario > > ___ > 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] a multislider GUI as abstraction
2016-06-26 16:35 GMT-03:00 IOhannes m zmölnig : > for me this sounds a bit like "i'd love to see them as externals totally sound like that :) *so* they can be included in some library" yeah, also like the idea of having it not as a single separate thing > would you care to explain what makes externals superior? > I don't think I'm the best one to discuss about the external x abstraction in terms of 'superiority', but yeah, I do like them better, I think they can be designed and work in ways that abstractions just don't (specially GUIs), and it's a common sense they are more efficient. In any way, I guess this discuss will touch known facts and issues and be subject to personal preferences. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] a multislider GUI as abstraction
On 06/25/2016 05:30 PM, Alexandre Torres Porres wrote: > I'd love to see them as externals and included > in some library for me this sounds a bit like "i'd love to see them as externals *so* they can be included in some library", which is factually wrong. if i just imagined the inference, would you care to explain what makes externals superior? gfmards IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] a multislider GUI as abstraction
2016-06-24 22:38 GMT+02:00 Roman Haefeli : > Hey Raphaël > > Hello Roman, and first : thanks a lot for feedback ! > Impressive work. I'm all for more advanced GUIs. I even like them being > abstractions as opposed to compiled externals. I'm not so concerned > about performance, since the GUI runs in a separate thread. I believe > it's rather GUIs like arrays that may cause hiccups when they send much > data in short time. > > Yes, I would be happy to contribute to such effort in pd. I found some other people working in this perspective of advanced abstraction-style-GUIs, especially I remember mmb's work for a "range" (2-points) slider, I don't know its author and if he/she reads the pd-list ? I'd be glad to participate in a collective effort to standardize and distribute a collection of these as library, why not ? > I do have some remarks. Some more steps were necessary for making it > work than mentioned in the instructions. > > * [iem_event] doesn't create, even after installing iemgui. Probably > you forgot to convert them to [library/objectclass] format. > > yes I had trouble with that. Indeed, in the version i provided, [iem_event] is created with the message [obj x y iem_event arguments arguments arguments... ( so without the [library/objectclass] format - as you can see in the subpatch [pd createVisualInterface] (in "initalize" section) and then [pd create_iem_event] But when I try to use [library/objectclass] format, I get this error message on instantiation : > iemgui/iem_event: already loaded many of them, i suppose a thousand of this error because it ends with the following : > maximum object loading depth 1000 reached > iemgui/iem_event 147 83 0 0 2321-event_s 2321-event_r > ... couldn't create Don't know what this means exactly, probably my mistake, I should try to reproduce this in a simpler patch. However since I put [declare -stdpath extra/iemgui], [iem_event] (without libraryname/ in object's name) does create for me. And without [declare] it created also but not on first opening... only after a moment it seemed to find the library... I didn't try to reproduce this, but again I'm confused with all the way of loading libraries. > * In addition to your library list, I also had to install mmb, which is > not yet available through Deken. > Oh, yes, this is a not finished part of it. At one time I found that I needed it, I think to handle $0-named receive, that can be saved as arguments, but I still need to dig in this part again. > > * I had to re-install zexy, since I was using the vanilla zexy compiled > as multi-object-single-file library. ph_msl currently works only with > zexy from extended that has each object in its own file. > Ah I'm not very aware of these different "flavors" of zexy, or don't really understand this multiple-flavor concept > > * I believe it would have been easier to [declare] all the libraries > instead of converting everything to [library/objectclass]. As a side > effect, this also means all dependencies are documented. Also, by using > [declare] you could make it work with any flavor of zexy, like [declare > -stdlib zexy -stdpath zexy]. > yes again, I am not very comfortable with the proper use of libraries, the "good practices" even if I try to follow the debates about it on the list, and reading [declare]'s help file didn't made me all clear... I was thinking that this way, the missing object would display the name of library from where they come in the "...couldn't create" error message. Also, I realized that the [prepend] objectname actually exists in two libraries, cyclone and iemlib... So I wondered what would happen if pd has to decide which library use to create the object, and found that could be a real problem if both homonym objects have very different function, or usage, inlets/outlets, etc... However, I might need a better understanding of [declare] because as said above it helped with [iemgui] for dealing with the issue of [iem_event] dynamic creation... If this is standard solution and actually the best way to make this abstraction easier to share, I'd be glad to rewrite everything and remove library in [objectsname] and [declare all the libraries] > > * Many external classes your patch uses can be easily implemented with > vanilla-only objects. For instance: > [zexy/makesymbol %s%s] -> [symbol $1$2( > [cycle/tosymbol]-> [makefilename %d] > [zexy/multiplex]-> [list prepend]\[nbx\ > [zexy/demultiplex] -> [route 0 1 2 3 4] > [moonlib/char2f]-> [list fromsymbol] > [moonlib/f2char]-> [list tosymbol] > (the list might be not complete) > > Yes I agree, and I know some of this tricks. However, it is sometimes faster to use this precisely-named utilities because it's shorter to write their name and easier read later. For example, I love [iemlib/once]. It's very easy to write, and much easier to read than the few vanilla objects that you would need to perform the same operation. I som
[PD] [envgen] and curves. Was: a multislider GUI as abstraction
Hi Raphaël, Sorry Fred, I remembered that when inside a gop abstraction, the displayed curve of [envgen] did let traces when its wrapping GOP-object was moved in edit mode. But that was a year or two ago, on windows, and now I can't reproduce this malfunction on my new setup (mac os X + pd-0.46-7 + ggee via deken). Maybe I will look into [envgen] or the ggee library. I found [envgen] has issues with its border being larger than the actual drawn rectangle as it requires a GOP window several pixels larger than its own size to be visible in the parent window. [tof/breakpoints], which is derived from [envgen] doesn't have this problem. So my mistake, sorry. I'll give a fresh look to [envgen]. But i always wondered if it would be complicate to have a few other features (like curved interpolation, or sort of bezier curve instead of only linear interpolation between points). Drawing curves is one thing, but the output format would also need to change; now it leaves the actual interpolation to [line~]. cheers, Raphaël Greetings, Fred Jan best regards, Raphaël Greetings, Fred Jan ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] a multislider GUI as abstraction
2016-06-24 22:16 GMT+02:00 Fred Jan Kraan : > Hi Raphaël, > > >> I love pd, but I miss some GUIs, like a good break-points curve editing >> (i am aware about [envgen] but it's buggy inside graph-on-parent), for >> envelopes or dynamic compressor ... >> > > Just today I completed a first reissue of the tof library containing > [breakpoints], a derivate of [ggee/envgen] for deken. I found it unstable > in edit mode, but not yet in a GOP. Can you describe the buggyness of > [envgen]? I could try to do something about it. > >> >> Sorry Fred, I remembered that when inside a gop abstraction, the displayed curve of [envgen] did let traces when its wrapping GOP-object was moved in edit mode. But that was a year or two ago, on windows, and now I can't reproduce this malfunction on my new setup (mac os X + pd-0.46-7 + ggee via deken). So my mistake, sorry. I'll give a fresh look to [envgen]. But i always wondered if it would be complicate to have a few other features (like curved interpolation, or sort of bezier curve instead of only linear interpolation between points). cheers, Raphaël > best regards, >> >> Raphaël >> > > Greetings, > > Fred Jan > >> >> >> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Experiencing a higher CPU load with 0.47-0 and 0.47-1.
Hi, list. I'm loading the same patch with 0.46-7, 0.47-0 and 0.47-1 - all 64bit. The last two have a significantly higher CPU load. I'm on OSX 10.11.5. Has any of you experienced anything similar? I haven't changed my [vd~] objects into [delread4~], are they calling the same piece of code? The patch is almost exclusively using signal objects, have some of these been modified in 0.47-0 and 0.47-1? Thanks for your help. Dario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
