Re: [PD] best non linear envelope design?

On Sat, Jul 13, 2019 at 7:59 PM Alexandre Torres Porres wrote: > yeah, both creb/eadsr~ and bsaylor/aenv~ seem to use a one pole filter > design, even though both generate slightly different shapes. > > Also mrpeach/rc~ does that. And banging the same value into a [line~] faster than it ramps

Re: [PD] best non linear envelope design?

yeah, both creb/eadsr~ and bsaylor/aenv~ seem to use a one pole filter design, even though both generate slightly different shapes. Em sáb, 13 de jul de 2019 às 20:40, Alexandre Torres Porres < por...@gmail.com> escreveu: > > > Em sáb, 13 de jul de 2019 às 05:40, Christof Ressi > escreveu: > >>

Re: [PD] OSC data from [list trim]

Ok, I see. Thanks. — Mitch > On Jul 13, 2019, at 4:09 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 2 > Date: Sat, 13 Jul 2019 21:55:58 +0200 > From: IOhannes m zmölnig mailto:zmoel...@iem.at>> > To: pd-list@lists.iem.at > Subject: Re: [PD] OSC data from

Re: [PD] OSC data from [list trim]

oscformat splits the address as symbols (aka strings), so the “1” in your address is actually a symbol and not a float which is why it doesn’t match. route doesn’t allow mixed symbols or floats so you need to create an empty route object and send a “symbol 1” message i to its right inlet with a

Re: [PD] OSC data from [list trim]

Am 13. Juli 2019 20:48:27 MESZ schrieb Mitchell Turner : >I guess I’m not clear on why the first element after [list trim] is a >symbol? > because [oscparse] splits the osc-path into symbols-only. mfg.fdz.gsf IOhannes -- sent from my pdp-12

Re: [PD] OSC data from [list trim]

Roman, Yes, I’m sorry I was not more clear. I should have begun the thread with: I’m receiving OSC messages in Pd from the iPhone app, TouchOSC. I think my fundamental misunderstanding was that the first item in the list is a symbol. It looked like a float, so I thought it was a float. Thanks

Re: [PD] OSC data from [list trim]

Christof, The first element of the list being a symbol is the exact problem and your split > float > append makes a functioning work around. Here is what I ended up with. [listen 8000( | | [netrecieve -u -b] | | [oscparse] | | [list trim] | | [list split 1] | | | | [f]| | |

Re: [PD] OSC data from [list trim]

On Sat, 2019-07-13 at 18:46 +0200, Christof Ressi wrote: > I think the problem lies somewhere else. There is a fundamental issue > with [oscparse]: it breaks the address pattern into its parts and > forms a Pd list, but treats numbers as symbols. Ah, thanks for pointing this out. From the

[PD] current GEM status?

Hi, I was never a GEM user, but I'm curious. What's the current status of GEM? I know it had suffered issues with macOS for ages. I remember a "christmas GEM" offer with a "pre build" that attempted to resolve all that. Now I see on deken that a 0.94 is available, maybe I missed the big

Re: [PD] OSC data from [list trim]

I think the problem lies somewhere else. There is a fundamental issue with [oscparse]: it breaks the address pattern into its parts and forms a Pd list, but treats numbers as symbols. In Mitchell's case, he might be sending an OSC message like "/1/toggle1 1", so [oscparse] outputs a list "1

Re: [PD] OSC data from [list trim]

On Sat, 2019-07-13 at 12:01 -0400, Mitchell Turner wrote: > > If I send this message “1 toggle1 1” to a [route 1], I expect the > message toggle1 1 to come out of the first outlet of route, however, > nothing comes out of the first outlet. There is a distinction in both worlds, Pd messages

[PD] OSC data from [list trim]

Dan, After reading your reply to a separate thread, I took a look at your MrPeach to vanilla OSC patch here: https://github.com/danomatika/BangYourHead/tree/master/6.Communication I am trying to adapt your patch to use

Re: [PD] Problems with oscformat (and oscparse?) and slashes

test 1:   > it does work if there is a list trim after oscparse, but it's confusing because there is no list indicator in oscparse's output   in this case, [oscparse] outputs a symbol, which is conceptually the same as a list with a single atom. [route symbol] will output a symbol again,

Re: [PD] Problems with oscformat (and oscparse?) and slashes

I think I delimited the issues more cleary, here is a patch that shows the problems. Am Fr., 12. Juli 2019 um 19:26 Uhr schrieb Christof Ressi < christof.re...@gmx.at>: > > but that will mean that for every new string, a new oscparse must be > created, in contrary to the current practice, where

[PD] Zoom factor and font sizes on Linux for 1920x1080 screen

Hi all, I have found some oldish discussions about similar topics ('implementing a zoom feature' was mentioned), so wondering what the current status for higher resolution displays on Linux is. I am, of course, referring to Pd Vanilla here. In particular I am running XFCE and am able to get

Re: [PD] best non linear envelope design?

Hey,   > I actually know of two other adsr envelopes out there for Pd, both non linear, they are: bsaylor/aenv~ and creb/eadsr~ - both are hardcoded.   attached you'll find my own personal envelope generator (cadsr~) which allows you to set the shape individually for each segments.

Re: [PD] best non linear envelope design?

On 13/07/2019 08:11, Alexandre Torres Porres wrote: the [adsr~] object, so far, is only linear, but I'm hoping to offer a hardcoded exponential setting for it, but not sure yet which one, hence my mail to the list Dear Alexandre Wouldn’t the “classical” approach be convex attack (0 < pow < 1)

Re: [PD] best non linear envelope design?

Em sáb, 13 de jul de 2019 às 04:36, matthew brandi escreveu: > On 13/07/2019 08:11, Alexandre Torres Porres wrote: > > the [adsr~] object, so far, is only linear, but I'm hoping to offer a > hardcoded exponential setting for it, but not sure yet which one, hence my > mail to the list > > > Dear

Re: [PD] best non linear envelope design?

Em sex, 12 de jul de 2019 às 22:30, Joey Dodson escreveu: > I'm curious about the range of values accepted. > For [envgen~], this is what I'm doing. The step variable is from 0 to 1 and reflects the vertical distance. The "delta" is the difference, if it's positive, then it's an ascending ramp,