Re: [PD] suggestion: $0 in messages
2018-04-01 18:51 GMT-03:00 IOhannes m zmölnig : > > like mostly, i'm opposing. > this has been discussed about 15 years ago, and my arguments still stand > (mainly: consistency with dollar-parsing throughout Pd) > Hi, just so I understand the issue, what complications would derive from this inconsistency? I'm cool if this has been discussed before and that this is the way it needs to be, but I'm just really curious. > apart from that, i wonder how you imagine your "external" (object) to > fix Pd's message-box. for an external, $0 is expanded as you'd like it > automatically anyhow. > not sure I get the question or what you want me to respond. Yeah, $0 normally expands it, so I figure it wouldn't be hard to do that. Well, if you're curious about the design, it'd be much like the same as a message box, but being able to expand $0, surely I'm thinking about other ideas, cause only this would be too little, for me, to motivate an external, so I'm guessing other things like being able to set the size and color and stuff. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] suggestion: $0 in messages
On 04/01/2018 10:42 PM, Alexandre Torres Porres wrote: > I just can't see how there could be any problem, or, in other words, I > can't see how $0 becoming "0" in messages is a desired feature or if anyone > could rely on this behaviour. "0" certainly isn't a good behaviour. > > But, if there's any concern or resistance to this, no problem, my > alternative would be to create an external that would do that. but then I'd > like to know here first where should I aim my efforts, if to a Pull Request > to Vanilla or to an external design. > like mostly, i'm opposing. this has been discussed about 15 years ago, and my arguments still stand (mainly: consistency with dollar-parsing throughout Pd) apart from that, i wonder how you imagine your "external" (object) to fix Pd's message-box. for an external, $0 is expanded as you'd like it automatically anyhow. gfamsrd 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
[PD] suggestion: $0 in messages
Hi, currently, if you want to use $0, you need an object cause it becomes "0" when it's inside messages. Pd-l2ork and Purr Data implemented a way that $0 works in the same way as in objects than in messages, and I think it is a great feature, as many patches can be significantly simplified. I guess most Pd users here know what I'm talking about. So, I'm interested in proposing that Vanilla includes such a feature. I'm trying to figure out how to do it myself and then send a Pull Request via github, but I'd like to also discuss here on the list if there'd be any concern in doing so. I just can't see how there could be any problem, or, in other words, I can't see how $0 becoming "0" in messages is a desired feature or if anyone could rely on this behaviour. But, if there's any concern or resistance to this, no problem, my alternative would be to create an external that would do that. but then I'd like to know here first where should I aim my efforts, if to a Pull Request to Vanilla or to an external design. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] jmmmp library Version 0.5 - R. Henke's Granulator
Hello everyone, The jmmmp library of abstractions has been updated. The newest object is Granulator, a Pure Data port of Robert Henke's Granulator. You can download it through deken, or follow the link below. For more informations and a tarball file, visit http://puredata.info/downloads/jmmmp/releases/0.5 Best, João Pais ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] sparse considerations about jit_expr (was: jit_expr 0.1: Just in time expr/expr~/fexpr~)
2018-04-01 5:46 GMT-03:00 mario buoninfante : > > as I said before I really like the idea of introducing a just in time > compiler, and I like the ideas you presented here. the only thing I'd say > is that I'd avoid introducing in Pd a pseudocode (max/gen~ style). > but besides pseudocode, Gen~ also deals with object boxes, for people who can't write text. It would be cool if we could take all of vanilla objects and compile it as an object for optimization, that would be like using Pd itself as a language and compile it like libpd. Am I dreaming? does something like this make sense at all? then, about having the possibility to write sample level patch in an > optimized way sounds amazing. I'm just wondering if it wouldn't be a better > idea trying to better integrate Faust. my only concern is about > maintainability of this new object family, JIT (in case we're talking about > a specific object family). Faust is already out there and works pretty fine > plus has an active and big community that constantly works to improve and > update it. > yeah, for what I hear, Faust would be nice, huh? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] add inlets to [ctlin]
Hi I0hannes, I totally agree with you about "premature optimization", but I'm pretty sure as well you agree we're not talking about GOTO statements here :D cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] sparse considerations about jit_expr (was: jit_expr 0.1: Just in time expr/expr~/fexpr~)
Hi Marco, as I said before I really like the idea of introducing a just in time compiler, and I like the ideas you presented here. the only thing I'd say is that I'd avoid introducing in Pd a pseudocode (max/gen~ style). in my opinion using (if possible) an existing scripting language (Lua, Python, etc ) would be a better option. then, about having the possibility to write sample level patch in an optimized way sounds amazing. I'm just wondering if it wouldn't be a better idea trying to better integrate Faust. my only concern is about maintainability of this new object family, JIT (in case we're talking about a specific object family). Faust is already out there and works pretty fine plus has an active and big community that constantly works to improve and update it. last but not the least, multithreading is obviously a good thing, but honestly do we really need to have something similar to what you described? don't get me wrong, the idea is cool and I only want to discuss these ideas, not criticize them. but personally, and of course I know everyone has different approaches and different needs, I think there's still a lot to explore before "moving to a multithreading dimension". also if it's a totally different situation (different hardware and programming language), I keep thinking about most of the commercial products, musical instruments (also the most complex) that are single thread based. mine of course are just thoughts. cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] add inlets to [ctlin]
Hi I0hannes, I'm with you, we are not talking about the most important improvement ever, but honestly still it is an improvement, and I can't see why don't do it :D I know that Pd could perfectly deal with tons of MIDI messages at time, but it's not only matter of dealing with them, but also the way it does it. the talking piano is really cool, I didn't know it. but it doesn't look like "performances" are really important in this situation (it's not a kind o f live processing integrated into a most complex system where time stuff matters), otherwise I'm pretty sure an improvement on [ctlin] would be really appreciated :D kiddin' cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
