• ddw_music

    This screenshot of a spectrogram recorded by alternating bob~ with a biquad low pass filter shows:

    • bob~ attenuates both low and high frequencies somewhat.
    • The biquad attenuates high frequencies significantly, but not low (the stronger band in the middle is resonance from Q).

    pd-2-filters.png

    bob~ doesn't sound to me like low pass, nor does its observed frequency response look like low pass.

    hjh

    posted in technical issues read more
  • ddw_music

    Ah, OK, that looks quite useful.

    If it sounds occasionally like I'm a bit cross with some of these questions, it's because of things like... this afternoon, I planned to largely finish my class slides for the filters lecture (brand-new class, so a lot of the material is new). Instead, I lost about 45 minutes trying to make a demo of biquad -> SuperCollider's SOS (second-order filter section) and then another two hours playing with various filter types in PD. So we're at the time when normal people get to go home from the office, and I haven't even started on what I was supposed to be working on.

    I get the feeling sometimes that Pd is a bit stubborn about the "vanilla" concept, at the expense of fundamental usability. I'm at pains to imagine a convincing reason why a modern audio programming environment should not have a 2nd-order resonant low pass filter built into the basic distribution. MSP has lores~. SC has RLPF. Pd has... "wish you luck finding an extension for it" (where the saving grace is the user community on this forum).

    Sorry. Just, one wasted afternoon later, I'm in a somewhat less than celebratory mood. I very much appreciate the simpler abstractions. Thanks!

    hjh

    posted in technical issues read more
  • ddw_music

    What is the easiest resonant lowpass filter to point students toward?

    bpf~ is bandpass. As far as I can see, so is bob~. (C'mon... any dance musicians will want a Moog-style lowpass filter...)

    As it stands right now, I can tell the students to add the mmb abstractions into their search paths and use [filtercoeff.mmb] --> [biquadm.mmb~] and that works great. And I don't mind to teach them about coefficients (it's a synthesis theory class -- I won't ask them to do the math themselves, but I do want them to be aware that coefficients exist and more or less what they mean).

    But I can't shake the feeling that there must be an easier way.

    hjh

    posted in technical issues read more
  • ddw_music

    Take a look at Ofelia

    Will do, thanks!

    My graphics knowledge lags pretty far behind my audio knowledge -- I might be leaning on the forum for a little while...

    hjh

    posted in pixel# read more
  • ddw_music

    OK, thanks. So I didn't really overlook anything ;)

    hjh

    posted in technical issues read more
  • ddw_music

    Suppose I wish to generate stripes with random widths.

    I can, right now, manually create a series of [translateXYZ] --> [rectangle] objects and, with the right numbers, I do get stripes.

    But maybe sometimes I need 3 really fat stripes and other times, 20 narrow ones. Or I want to fill up a total distance of 1.5 with randomly-sized stripes and random distances between them, so that the total number of stripes is not known in advance.

    If every stripe must be an individual [rectangle], then I'm afraid I don't see how to do it.

    High-level jiujitsu trickery is welcome :smiling_imp:

    hjh

    posted in pixel# read more
  • ddw_music

    If I have a linear breakpoint envelope shape that I would like to run in a loop, what is the best way to do this?

    It's straightforward to produce the shape once with vline~ -- somewhat less straightforward with line and line~ but OK.

    What I really miss is the right-hand "bang" outlet that these objects have in Max. Sure, I can do a [t b b] and put one of the bangs into a [delay] matching the time until the next repeat, but... it's a lot easier if the ramp generator just tells me when it's finished.

    hjh

    posted in technical issues read more
  • ddw_music

    @seb-harmonik.ar Thank you! It took me a long time to get around to this, but I finally put the reader and writer into subpatches and indeed, that sorts it. Thanks!

    hjh

    posted in technical issues read more
  • ddw_music

    The attached patch "should" produce a bandlimited square wave at 523.2 Hz (using the sawtooth/delay/subtract trick). But the oscilloscope array shows a smaller-than-expected pulse width.

    I think my math is right: delay time in ms = 1000 / freq * pulse width. But the delay time is slightly off from where it should be.

    I'm pretty sure, if I do the same with SuperCollider's Saw and DelayC units, the pulse width renders as expected. So I think there is some inaccuracy with delread4~'s delay time. Or something else?

    19-0902-pulse-wave.pd

    hjh

    posted in technical issues read more
  • ddw_music

    @seb-harmonik.ar > cyclone/reson~ seems somewhat similar

    Tried it -- with Q up around 500, it's pretty close in a side-by-side comparison against Ringz.

    It'll take some more trial and error to get the attack/decay variant working -- Ringz's constant skirt gain works out so that Ringz(highQ) - Ringz(lowerQ) suppresses some of the input, while [cyclone/reson~ ... highQ] - [cyclone/reson~ ... lowerQ] doesn't, because the lower Q filter is a lot louder.

    Thanks!

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!