Re: [PD] vanilla replacement for mrpeach/routeOSC
In case it's of use, I had this problem as well, and did the fiddly arcane method for pure vanilla. See this patch, and look in the abstractions 'oscparse-mobmuplat' and 'oscformat-mobmuplat'. They take the oscparse/oscformat message convention (i.e. spaces) and turn it into an address with slashes (and vice versa). https://github.com/monkeyswarm/MobMuPlatEditor/blob/master/Shared/PdWrapper.pd Usage [netreceive -u -b] | [pd oscparse-mobmuplat] | (use list containing an OSC message like '/foo/bar 0 1 2 3' ) and (list containing an OSC message like '/foo/bar 0 1 2 3') | [pd oscformat-mobmuplat] | [netsend -u -b] Let me know how it goes... On Tue, Apr 30, 2019 at 3:19 PM Christof Ressi wrote: > Thanks. The idea really came from zexy's l2s and s2l objects which I use > so often that I thought I have to reimplement them for Pd vanilla. > > > String processing is one area that Pd doesn't exactly lead the pack, > > I'm secretely dreaming about regex support for [text] :-) > > > Gesendet: Dienstag, 30. April 2019 um 23:57 Uhr > > Von: "Philip Stone" > > An: "Christof Ressi" > > Cc: "pd-list@lists.iem.at" > > Betreff: Re: [PD] vanilla replacement for mrpeach/routeOSC > > > > Christof, > > > > Your proposed new list methods are excellent, and would be extremely > useful in many contexts. String processing is one area that Pd doesn't > exactly lead the pack, but your improvements would go a long way towards > fixing that. > > > > > > Phil Stone > > UC Davis > > > > On 4/30/19, 2:48 PM, "Christof Ressi" wrote: > > > > > [list fromsymbol] -> [convert ‘/’ to space] -> [list tosymbol] -> > [route] > > > > that won't work because [list tosymbol] will output a single symbol > with whitespace characters. > > > > what you want is: [list fromsymbol] -> [convert ‘/’ to space] -> > [fudiparse] > > > > BTW, I've just recently proposed new list methods for exactly such > use cases: https://github.com/pure-data/pure-data/pull/595 > > > > Christof > > > > > > Gesendet: Dienstag, 30. April 2019 um 18:47 Uhr > > Von: "Philip Stone" > > An: "pd-list@lists.iem.at" > > Betreff: [PD] vanilla replacement for mrpeach/routeOSC > > > > I had some spare time to go back to my old Pd synthesizers and > thought I’d try to see if recent developments in vanilla Pd could help me > remove some of my external dependencies. > > > > [oscparse] works great when taking FUDI in from [netreceive], and > converting the multi-level OSC message into a list of separate symbols. > However, it’s no help when dealing with OSC messages not originating from > the network – i.e., ones passed around internally. I use internal OSC > messages a great deal in my synthesizers, and need an efficient way to > route them. > > > > I can imagine a fairly arcane method: use [list fromsymbol] -> > [convert ‘/’ to space] -> [list tosymbol] -> [route]. I fear, however, > that this will be much less efficient than [routeOSC], especially the > list-drippy [convert ‘/’ to space] part. > > > > Are there any (vanilla) alternatives to this? > > > > > > Phil Stone > > UC Davis > > ___ 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] vanilla replacement for mrpeach/routeOSC
Thanks. The idea really came from zexy's l2s and s2l objects which I use so often that I thought I have to reimplement them for Pd vanilla. > String processing is one area that Pd doesn't exactly lead the pack, I'm secretely dreaming about regex support for [text] :-) > Gesendet: Dienstag, 30. April 2019 um 23:57 Uhr > Von: "Philip Stone" > An: "Christof Ressi" > Cc: "pd-list@lists.iem.at" > Betreff: Re: [PD] vanilla replacement for mrpeach/routeOSC > > Christof, > > Your proposed new list methods are excellent, and would be extremely useful > in many contexts. String processing is one area that Pd doesn't exactly lead > the pack, but your improvements would go a long way towards fixing that. > > > Phil Stone > UC Davis > > On 4/30/19, 2:48 PM, "Christof Ressi" wrote: > > > [list fromsymbol] -> [convert ‘/’ to space] -> [list tosymbol] -> > [route] > > that won't work because [list tosymbol] will output a single symbol with > whitespace characters. > > what you want is: [list fromsymbol] -> [convert ‘/’ to space] -> > [fudiparse] > > BTW, I've just recently proposed new list methods for exactly such use > cases: https://github.com/pure-data/pure-data/pull/595 > > Christof > > > Gesendet: Dienstag, 30. April 2019 um 18:47 Uhr > Von: "Philip Stone" > An: "pd-list@lists.iem.at" > Betreff: [PD] vanilla replacement for mrpeach/routeOSC > > I had some spare time to go back to my old Pd synthesizers and thought > I’d try to see if recent developments in vanilla Pd could help me remove some > of my external dependencies. > > [oscparse] works great when taking FUDI in from [netreceive], and > converting the multi-level OSC message into a list of separate symbols. > However, it’s no help when dealing with OSC messages not originating from the > network – i.e., ones passed around internally. I use internal OSC messages a > great deal in my synthesizers, and need an efficient way to route them. > > I can imagine a fairly arcane method: use [list fromsymbol] -> [convert > ‘/’ to space] -> [list tosymbol] -> [route]. I fear, however, that this will > be much less efficient than [routeOSC], especially the list-drippy [convert > ‘/’ to space] part. > > Are there any (vanilla) alternatives to this? > > > Phil Stone > UC Davis > ___ 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] vanilla replacement for mrpeach/routeOSC
> [list fromsymbol] -> [convert ‘/’ to space] -> [list tosymbol] -> [route] that won't work because [list tosymbol] will output a single symbol with whitespace characters. what you want is: [list fromsymbol] -> [convert ‘/’ to space] -> [fudiparse] BTW, I've just recently proposed new list methods for exactly such use cases: https://github.com/pure-data/pure-data/pull/595 Christof Gesendet: Dienstag, 30. April 2019 um 18:47 Uhr Von: "Philip Stone" An: "pd-list@lists.iem.at" Betreff: [PD] vanilla replacement for mrpeach/routeOSC I had some spare time to go back to my old Pd synthesizers and thought I’d try to see if recent developments in vanilla Pd could help me remove some of my external dependencies. [oscparse] works great when taking FUDI in from [netreceive], and converting the multi-level OSC message into a list of separate symbols. However, it’s no help when dealing with OSC messages not originating from the network – i.e., ones passed around internally. I use internal OSC messages a great deal in my synthesizers, and need an efficient way to route them. I can imagine a fairly arcane method: use [list fromsymbol] -> [convert ‘/’ to space] -> [list tosymbol] -> [route]. I fear, however, that this will be much less efficient than [routeOSC], especially the list-drippy [convert ‘/’ to space] part. Are there any (vanilla) alternatives to this? Phil Stone UC Davis ___ 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] vanilla replacement for mrpeach/routeOSC
I had some spare time to go back to my old Pd synthesizers and thought I’d try to see if recent developments in vanilla Pd could help me remove some of my external dependencies. [oscparse] works great when taking FUDI in from [netreceive], and converting the multi-level OSC message into a list of separate symbols. However, it’s no help when dealing with OSC messages not originating from the network – i.e., ones passed around internally. I use internal OSC messages a great deal in my synthesizers, and need an efficient way to route them. I can imagine a fairly arcane method: use [list fromsymbol] -> [convert ‘/’ to space] -> [list tosymbol] -> [route]. I fear, however, that this will be much less efficient than [routeOSC], especially the list-drippy [convert ‘/’ to space] part. Are there any (vanilla) alternatives to this? Phil Stone UC Davis ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] music DSP job, Fender, Scottsdale, AZ, USA
(looks on slightly enviously from afar) That'll be a nice gig for some lucky soul. As an aside -- I went to NY in my early 20's and ended up in Manny's (famous guitar shop). Had a go on a '58 Fender Precision, all the paint worn off the back of body and neck, still had the bell over the bridge - most expensive bass in the shop at the time (circa $5k in 91). I'm still occasionally back in that space, happily blissed out and idly lost in the moment. Replicating that'd be some heavy hocus pocus dsp-sauce manoeuvrer (sans the smell:) J. On Tue, 23 Apr 2019 at 18:32, Miller Puckette wrote: > Apologies if this is too far off topic but I bet some Pd-er in Scottsdale > will want to know about this... > > On Mon, Apr 22, 2019 at 09:41:50PM +, Jesse Pfeister wrote: > > Hello. When hiring for music-oriented DSP roles at Fender, we want to > improve > +our outreach to university students majoring in the relevant fields. > > > > Do you know of any boards or mailing lists we can post to? Is there > someone > +more appropriate we should be e-mailing? > > > > Thanks for any help you can provide. > > > > Here's an example of one we have active right now: > > https://www.fender.com/pages/careers?gh_jid=1583445 > > I offered to forward it and told him it was fine if he wanted to join the > list and keep us in the know in the future. They're looking for a BA/BS > level > DSP programmer at the moment. > > cheers > Miller > > > > ___ > 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] [keyname] for space bar toggles upper/lowercase
On 30.04.19 15:49, Peter P. wrote: > Hi, > > I just found out that the keyname for space bar is spelled > Space > or > space > depending on if it is a key up or down. Can anyone confirm this on a > non-Linux OS? on windows you always get "Space". afaict, this is related to the other issue (KeyRelease returning 0 for numbers on linux) 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] get keyboard events without repeats (in 2019)
On 30.04.19 15:41, Peter P. wrote: > Katja, > > I am trying to use your idea about holding back key ups. However it > seems that [keyup] outputs 0 for letter keys, and numbers for the number > keys. I can't seem to figure out why. i would say that this is a bug. (it works as epxected on windows - at least under wine) the problem seems to be on tcl/tk side. fgamsdf 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] [keyname] for space bar toggles upper/lowercase
Hi, I just found out that the keyname for space bar is spelled Space or space depending on if it is a key up or down. Can anyone confirm this on a non-Linux OS? cheersio, P ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] get keyboard events without repeats (in 2019)
Katja, I am trying to use your idea about holding back key ups. However it seems that [keyup] outputs 0 for letter keys, and numbers for the number keys. I can't seem to figure out why. But it has the consequence that your nice idea will possibly not work if two or more keys are held down together. Seems this one is not (yet) solved for me. Thanks again! P * katja [2019-03-18 18:09]: > One workaround (that I'm using in practice since long) is to hold back > the keyup message for slightly longer than the repeat time, and only > let it through when keydown didn't come again in the meantime. The > method introduces latency on keyup but not on keydown. See attached > patch, it is slightly too complicated for ASCII illustration. > > Katja > > > On 3/18/19, Peter P. wrote: > > Hi list, > > > > chiming in to the discussion of possible improvements regarding mice and > > now also keyboards, I am wondering if there could be a way within Pd to get > > keyboard events without having the operating systems (all three of them) > > repeat key down/up events in rapid succession. > > > > I know that I can tell the operating systems to disable it but would > > absolutely prefer Pd's keyboard objects to get these without repeats. > > > > Happy to hear any feedback on that! > > P > > > > > > > > ___ > > 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] get keyboard events without repeats (in 2019)
Christof, I am not sure if your abstraction behaves on my OS as you conceived it. Key entries in the table do not get reset. Subsequent key downs hang therefore indefinitely... * Christof Ressi [2019-03-18 17:44]: > for non-control keys this can be easily done in an abstraction (see > attachement), but for control keys it's a bit more involved, so I agree that > this would be a nice feature! it wouldn't be hard to implement in > [key]/[keyname]. maybe just make a feature request on GitHub. > > Christof > > > Gesendet: Montag, 18. März 2019 um 17:20 Uhr > > Von: "Peter P." > > An: pd-list > > Betreff: [PD] get keyboard events without repeats (in 2019) > > > > Hi list, > > > > chiming in to the discussion of possible improvements regarding mice and > > now also keyboards, I am wondering if there could be a way within Pd to get > > keyboard events without having the operating systems (all three of them) > > repeat key down/up events in rapid succession. > > > > I know that I can tell the operating systems to disable it but would > > absolutely prefer Pd's keyboard objects to get these without repeats. > > > > Happy to hear any feedback on that! > > P > > > > > > > > ___ > > 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] 'Find externals' under Wine
On 29.04.19 19:23, Roman Haefeli wrote: > I > wonder if extracting fails because the downloaded file is renamed: > > osc[v0.2~git20181006](Windows-amd64-32).dek -> > osc[v0.2~git20181006](Windows-amd64-32).dek.zip > > Somewhere a .zip extension is appended to filename, .zip files end up > with .zip.zip. afaict, wine fails to unzip because it simply doesn't come with a built-in unzip utility (unlike proper windows). e.g. you (at least: I) cannot unzip a zip-file in the wine-explorer by any means. the reason why the files are renamed, is that the built-in unzip utility on windows will only start working if it believes that the file it is supposed to unzip is a zip-file. windows being windows, this means that the file must have a .zip extension. So after downloading the deken package, we just rename by adding a .zip extension (there's no check whether the file already had a zip-extension (old-style deken packages), that's why you get a .zip.zip extension; afaict there's no problem with that, as windows still trusts that the file is a zip-file). in any case, the file should be renamed back to the original name after the unzip attempt (whether successful or not), so i wonder why you see these files in the first place. (the time window where the .zip extension is present should be pretty small for a failing unzip attempt; it should definitely be gone once the exploder is fired up) dmasr 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
