Re: [PD] [env~] issues
seems similar to the one used to make delay line shorter than one block. and how is that trick? :) 2014-12-16 11:41 GMT-02:00 IOhannes m zmölnig zmoel...@iem.at: On 12/15/2014 11:53 PM, Raphaël Ilias wrote: Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) mfgadsr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
That's definitely a workable solution. But if it were truly trivial then [trigger] wouldn't exist. -Jonathan On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig zmoel...@iem.at wrote: On 12/15/2014 11:53 PM, Raphaël Ilias wrote: Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) mfgadsr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
On my side i would not say it is exactly trivial JmAdrien Le 16 déc. 2014 à 16:59, Jonathan Wilkes via Pd-list pd-list@lists.iem.at a écrit : That's definitely a workable solution. But if it were truly trivial then [trigger] wouldn't exist. -Jonathan On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig zmoel...@iem.at wrote: On 12/15/2014 11:53 PM, Raphaël Ilias wrote: Ok, I get the trick, it seems similar to the one used to make delay line shorter than one block. However, I still feel that an object give-me-RMS enveloppe-on-bang (for the last N samples or blocks) would appear to me an easier way to handle this case. If it doesn't exist, I'll try to build something like this... one day ! Many thanks ! oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) mfgadsr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] allpass~ Max5 doc
Hi Alexandre, seems like a mistake I don't have Max 5, but in Max 6 it's pretty clear it's only 3, and in cyclone, for what I see, i'ts also only 3, right? Yes, the object code only uses three arguments. I've seen some typos and misleading things in Max's documentation before, it can happen. From a PM I understand the typo is fixed in the Max 6 documentation. cheers Greetings, Fred Jan 2014-12-15 18:26 GMT-02:00 Fred Jan Kraan fjkr...@xs4all.nl mailto:fjkr...@xs4all.nl: Hi all, Checking the number of argumens allpass~ should have, I find an unclarity in the Max5 reference doc. It states: Up to four numbers, to set the maximum delay time and initial values for the delay time D and gain coefficient g. What I read here is saying there are four, but the description mentions only three. The rest of the description gives the impression there are three parameters, one to be set as argument, the other two either as argument, float or signal. Maybe someone with better command of the English language can say if there is a probably typo here or that I don't grok it at all. Thanks, Fred Jan ___ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone help patches issue list
On 2014-12-15 22:46, Miller Puckette wrote: Just FYI…. Joe Deken of newblankets.org is considering making a repository of external objects compatible with Pd vanilla. I think almost all the objects in Pd extended will work with vanilla (and if I find out what specific changes vanilla would need to allow the others, I'd be happy to try to provide them). It seems like maintaining compiled versions of the libs is an easier thing to do than maintaining all of Pd Extended. I heard about that. It could neatly solve the distribution problem and make the corpus of pd-extended libraries more manageable by splitting it up. It there is a pilot-program, I would happy to be part of it. cheers Miller Greetings, Fred Jan On Mon, Dec 15, 2014 at 07:36:59PM -0200, Alexandre Torres Porres wrote: I could put the compiled libraries somewhere online, but do not expect a neat installer. No need for installers. If it's somewhere just compiled for the major systems and with the source code for nerds everywhere is cool ;) There is no indication a new Extended release will happen any time soon. I know, that's a bummer :( and that's why putting the library for download seems important. the formula in the code is the same as found in the Max5 documentation yeah, but does it show you how to calculate the coefficients besides the formula? cheers 2014-12-15 16:08 GMT-02:00 Fred Jan Kraan fjkr...@xs4all.nl: Hi Alexandre, Sorry, yes pd-extended 0.44. sure, but when I first mentioned about versions, I was thinking about cyclone's own version number. I assume there's one, right? And I also assume you have it for download somewhere for people to include it in Pd Vanilla. Where can we get it? Currently it appears only in the pd META sub-patch of the help-patches. It is currently 0.1-alpha56. Adding it to each object would be a good thing and report it at load time (Debug-level). But this would mean changing all objects. Something for the todo list. Currently there are only some patches in the patch tracker, and linux 32 bit executables on my harddisk. The idea is to test them on several platforms, including linux 64 bit, Windows 32 bit and Macos X 10.7 (64 bit). I could put the compiled libraries somewhere online, but do not expect a neat installer. I would consider it a temporary stop-gap for the time there is no proper distribution. If Extended keeps on delaying too much for an update, I'm gonna start just getting all the libraries I use into vanilla :( There is no indication a new Extended release will happen any time soon. cheers ps. while we're at it, I have a question, are [lores~] and [reson~] perfect copies of the Max's objects, same formula and everything, or just something similar? The objects should be proper clones, but I haven't checked them in that much detail. At first glance I would say, the formula in the code is the same as found in the Max5 documentation. Greetings, Fred Jan ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
On Tuesday, December 16, 2014 8:47 AM, IOhannes m zmölnig zmoel...@iem.at wrote: oh, but that is just trivial: Le 16 déc. 2014 à 16:59, Jonathan Wilkes via Pd-list pd-list@lists.iem.at a écrit : But if it were truly trivial then [trigger] wouldn't exist. On 12/16/2014 05:06 PM, Jma/celeonet wrote: On my side i would not say it is exactly trivial what i meant with trivial was easily solveable using well-known techniques like [trigger]. the problem itself is not trivial at all if you don't have [trigger]. fdsar IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] error: canvas: no method for 'f'
hi, i know it's been on the list before, but googling didn't give me anything. the change log for Pd Vanilla did not help either. i (think to) know it's caused by an extra parameter for some object but which object? for me it's necessary to be able to run my patch in Pd 42.5. thanks in advance, rolf ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] error: canvas: no method for 'f'
This is caused when you make a patch in 0.45 or later, make some object have non-default text width, and then open it in an eralier version of Pd (such as extended, which is 0.43). It shouldn't hurt anything (but will lose the formatting information). If you save in the older version of Pd the f messages and the error messages will go away. (You can also hand edit them out of the patch if you want.) cheers Miller On Tue, Dec 16, 2014 at 07:19:31PM +0100, ro...@dds.nl wrote: hi, i know it's been on the list before, but googling didn't give me anything. the change log for Pd Vanilla did not help either. i (think to) know it's caused by an extra parameter for some object but which object? for me it's necessary to be able to run my patch in Pd 42.5. thanks in advance, rolf ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone help patches issue list
Sorry, I didn;t mean to sound like I'm griping. The nature of the question was more if we apply clean, small patches to vanilla, could we get some of Han's updates in so they aren't lost to non Pd-l2ork users. I'm in the middle of writing my thesis right now, but getting into real Pd development again is on my list when I'm finally done with it. On Tue, Dec 16, 2014 at 5:59 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 12/16/2014 03:12 PM, Dan Wilcox wrote: I like how I explicitly asked to not hear that Pd-l2ork has that and yet that's the response I got. I already knew this anyway from the sample screenshots you were posting when you were implementing it. (Looks great BTW) Yeah, I know, it was 100% willful snark on my part. It's kind of like you were asking, Is there a way to do X, while satisfying my irrational desire to ignore a working solution by someone who likely already did X? Anyway, did you look at the code? It's done in tcl/tk, and it does not depend on tkpath. So if you don't want to duplicate all the work I already did, you can fairly easily port that back to Pd Vanilla. There might be a few API differences in accessing the audio backend, but there are small and I don't mind helping make those changes. Also, I specifically did everything in tcl/tk so that the patch would be as simple as possible. It shouldn't even require a recompile. Now, I haven't looked at Ivica's changes that added persistence. But all versions of Pd have the same prefs-saving code so that shouldn't be difficult, either. Also, if you didn't know, why respond? :P Because the answer to your question ultimately depends on whether what you come up with fits the unspoken yet stringent HIG standards imposed by Miller's Pd. But that doesn't mean that code which does _exactly_ what you're asking about isn't relevant to your question. -Jonathan On 12/15/2014 06:21 PM, Dan Wilcox wrote: If that does become a real scenario, I hope we can find a way to bring some of the Pd-extended UI changes into vanilla, such as the pixel perfect sizing across platforms, an option for the extended coloring (graytones) etc. Before anyone says “Pd-Lork has that”, I’m just wondering if it’s feasible to bring in some of the work Hans did after the gui cleanup which is already in vanilla. In answer to your question: I don't know. Having answered that... Pd-l2ork has gui theme presets for Vanilla, Inverted Vanilla, Pd-extended, Commodore 64, Strongbad's Compy, and a few others. There's also an interface to make a custom theme-- I didn't make it persistent but I think Ivica added that ability. -Jonathan -- Dan Wilcox danomatika.com robotcowboy.com -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PdDroidParty latency, syncing etc.
Hi Gavin, My Moto G doesn't report a unique network id for some reason. This is a fairly critical bug. The protocol won't behave well if a node is lacking a uid. After looking at the uid object I think this could happen if a device lacks the loopback interface 127.0.0.1 - so I've changed the code so that a) it tries to gather network entropy by connecting to 0.0.0.0 instead and b) it falls back to just using the startup entropy if the network entropy fails. I have pushed this code - do you mind testing again? On 16/12/14 06:48, Gavin wrote: Quick update - I got rid of the 255.255.255.255 broadcast option and it seemed to make things much better, though still not perfect. Is the patch meant to choose Android network broadcasting (192.168.43.255) if available and if not then fall back to lan blanket broadcasting? I'm not sure but for me, both spigots were open and I think the network was getting congested. The protocol is designed so that it can send on as many interfaces as possible redundantly. This is so in future I can drop in other transports like mesh networking and whatever packets make it through first will be the ones that get used. Because each message gets a unique ID the protocol can easily drop redundant messages. Because of the way that message retries work (based on a simple checksum of the state hash) if something is broken with the uids it will probably result in a lot of traffic as the nodes try and get the broken node up to date. I probably need to include a retry counter where if a node is continuously behaving badly it gets ignored by the other nodes eventually, say after 100 retries. I'll add that to the TODO. Now it works much better but there is still some lag and I am getting alot of $2 : argument out of range messages - not sure where they originate from. That's not good. Those were plaguing me and I could not find the source, but they went away when I got all the other bugs ironed out. Can you let me know if the latest from GitHub exhibits the same symptoms? https://github.com/chr15m/SyncJams Thanks for testing! Cheers, Chris. -- http://mccormick.cx/ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
