• chvolow24

    @ddw_music Undesirable behavior at a 0Hz cutoff makes sense, though I think what's most surprising to me is that the filter still produced a signal when the filtered signal (the leftmost inlet) was also at 0. But there's a lot I don't understand about the mechanics of how these filter work, so I shouldn't be surprised. Moving the amp env downstream is an easy fix that should work. thanks so much for your help!

    posted in technical issues read more
  • chvolow24

    Hello!

    I'm encountering a behavior with the vcf~ object that I don't understand, and I think it's contributing to a lot of popping noises being produced by my patch.

    The behavior is this: even when the first and second vcf~ inputs stabilize at 0, I'm seeing an extremely low-amplitude, low-frequency signal continue to be output by the the vcf. It appears to have something to do with the middle inlet, as if vcf stops accepting inputs just before they reach 0.

    I've included a simple patch here that illustrates the problem. The test frequency is defined by a phasor~, and both the test frequency amplitude and the center frequency itself are controlled by a simple ADSR envelope. The two inlets to vcf~ are snapshotted, as is the output, so you can see that even when the inputs go to 0, the output oscillates, very slowly and quietly.

    I would massively appreciate any insight anyone has into this!

    Thanks,
    Charlie

    vcf_weird_output.pd

    posted in technical issues read more
  • chvolow24

    @myQwil @whale-av @ingox
    Y'all are great. @ingox wins the prize for simplicity & elegance (I'm implementing this solution now), but I learned something valuable from each of these replies. Thanks!!

    posted in technical issues read more
  • chvolow24

    Hey, anyone know a good way in pd vanilla to check a number stream against a list, and output a bang if the number is in the list?

    I've used awful, brute-force solutions to this problem with tons of [sel] objects and message boxes, but these are messy and inflexible. It's a simple challenge logically, so I'm hoping there's a better solution.

    My brute force solution (only one [sel] object shown, but in reality there would be one [sel] for each [$n]:

    [float]      [list]
       \         / | \ 
        \    [$1][$2][$3] (etc., *n)
         |     \ | /
         [sel  (*n) ]

    posted in technical issues read more
  • chvolow24

    Thanks David. I wasn't able to filter the bangs without blocking repeated notes as well, but ultimately got much closer to what I was looking for by sending [ctlin] values over a separate port. This will still come in handy!

    posted in technical issues read more
  • chvolow24

    Hi all,

    Working on sustain pedal functionality for the first time, and running into problems. The attached patch basically filters out noteoffs with [stripnote], and sends them separately if the pedal value is 0. If the pedal value is nonzero (depressed), it stores the noteoffs in the [bag] object and flushes when the pedal value returns to 0.

    Unfortunately, some voices are held when they shouldn't be, and I can't really figure out why. The note-offs seem to be sending correctly.

    One potential problem is that the udp connection I'm using to get the midi data in is banging all of the outputs with every change -- so, changes in what is originally the [ctlin[ value send repeated bangs to the note and velocity streams. In other words, depressing or releasing the pedal sends bangs through the note-on pathway even though the note and velocity values aren't changing. If that is the problem, how can I remove the bangs from those number streams? the path here leading to [stripnote] should only be banged with a new note, not a pedal change.

    Any help would be hugely appreciated! I may be missing something simple and obvious.

    sustain.pd

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!