• dwan

    thanks for checking ! Also working for me...

    posted in this forum read more
  • dwan

    Someone in the facebook pd group reports not receiving his confirmation email. Spam folder checked, etc. https://www.facebook.com/groups/puredata/permalink/10156627438764495/

    posted in this forum read more
  • dwan

    1. You should use Pd vanilla + needed externals. Pd-extended is not maintained anymore, which means that should you encounter bugs with it (and there are), they won't be corrected, like, ever.

    2. This is not how you bypass a filter. Remember that toggles can take 2 values, 0 and another one (typically 1) when clicked. Your slider sends a float to the atom, which sends the float to the toggle, which hands it to the [hip~], which understands the float as a frequency value to set the filter. When you click the toggle, it sends a zero, which sets the hi-pass filter to zero hertz and thus gives the wrong impression that it's bypassed when actually you just set it to its lower value. Eventually, this trick doesn't work with [lop~], because a low-pass filter set at zero hertz acts almost like a mute button.

    3. Then, how to bypass signal object ? You have to come out with a way to make the signal go to your filter OR to the next object.

    See this example of how to do this. This is only one way to do, there are many : bypass-example.pd

    PS : i was very intrigued by this behaviour of [tgl] that would alternate between zero and the last non-zero value that went through. I remembered seeing this a long time ago... Eventually, this behaviour was ditched with 0.46 but we still have a compatibility mode. Another reason to let Pd-extended go, i guess !

    posted in technical issues read more
  • dwan

    Very nice work, it sounds great !

    posted in output~ read more
  • dwan

    [vline~] can process different ramps inside of a block (whereas [line] and [line~] are bound to the block boundaries), and can even start and stop ramps in-between samples (cf. help file). So i guess that if you send the right message with the right succession of ramps, it's ok !

    posted in technical issues read more
  • dwan

    If you want to be very explicit (and almost pd-pedantic :) ), use [+~}.
    But really, no one (?) does this, and you can just connect each source directly to the filter which will take care of the adding process.

    posted in technical issues read more
  • dwan

    @greycat Well, it alls depends on what you want to achieve :

    • if you multiply [osc~] output with another signal [0;1], you make its amplitude vary between nothing and full amplitude

    • if you add [+~ -0.5] to a [phasor~], you basically remove the DC component of the ramp oscillator

    • if you multiply the output of two [osc~], you're doing Amplitude Modulation (AM)

    • if you add the output of two [osc~], you're doing additive synthesis

    posted in technical issues read more
  • dwan

    It's not a bug for me as long as the "right" way to do such a feedback path is mentioned in the documentation. [urn] has the same "issue" because the morphology of the patch (the feedback path) is the same as with [sel].

    posted in patch~ read more
  • dwan

    @whale-av said:

    @ketchupee1 like this.......... golf.pd
    It is all in the message order...... http://puredata.info/docs/manuals/pd/x2.htm

    Your patch does not give an output on each bang :)

    But your reference to the manual gives the solution that i used, and even a [del 0] would work !

    it is legal to make a loop if there is a "delay" object somewhere in it. When the "delay" receives a message it schedules a messsage for the future (even if the time delay is 0) and is then "finished;" Pd's internal scheduler will wake the delay back up later.

    posted in patch~ read more

Internal error.

Oops! Looks like something went wrong!