I should add that using fudiparse works fine:

[netreceive -u -b 5400]
|
[fudiparse]
|
[unpack %f %f]

My expectation was that the above patch was equivalent to this:

[netreceive -u 5400]
|
[unpack %f %f]

But the latter does not work now.

I'm having a problem with receiving FUDI data sent over UDP.

The datagrams are being received, and I can print the byte values:

[netreceive -u -b 5400]
|
[print]

sample output:

print: 52 56 48 32 52 59
print: 49 57 50 32 51 59
print: 49 57 50 32 51 59
print: 49 57 53 50 32 52 59
print: 49 57 53 50 32 52 59

But without the -b flag, nothing is printed. The byte values look like correctly-formatted FUDI to me: two atoms, separated by a space, terminated by a semicolon.

This was working for me yesterday and I'm not sure what changed.

Thanks David! The subpatch solution worked perfectly, and this is all very helpful.

The DAW is my own, so I'm in control of that end of the connection, and there is a block size negotiation. The errors in the signal at blocksize 64 are probably due to shortcomings in my implementation of the synchronization between the two programs, which uses two named semaphores for writing to and reading from a shared memory block. The actual transfer is just a memcpy. Checking out other folks' VST externals is a great suggestion -- I'll definitely do that.

charlie

Hey all,

I've written an external to send audio data from Pd to a DAW that I'm working on. To get the signal through with no errors, I need to increase the DSP block size to 512, which I'm doing with [block~ 512 1 1]. This works fine for my external, but seems to break [dac~]; upon enabling DSP, the error int he title is printed to the console, and no audio output is heard. I also changed the block size in audio settings to 512, which I thought would solve this. My expectation was that the 'Pd vector size' is set by [block~], and the dac~ input vector size is determined by the audio setting. If both are 512, then why might I get this error?

Thanks both! I'm always amazed by the speed on here; this is the best forum on the internet

Is there a way to change the target of a [receive] object the way one can with [send] when it is invoked with no arguments? It seems that there is not, but I'm unsure.

Thanks!
charlie

Hi all,

I have a large patch with many layers of depth that's basically an imitation of old user-configurable synthesizers. Included is the ability to save presets, which is accomplished by writing values from all "send" objects to a text file, which can be read later (e.g. filter adsr, vibrato/tremolo frequency and depth, ring mod, etc.)

The challenge I'm encountering is simply that it's cumbersome to add each new "variable" to the logic that writes and reads these presets, and as the number of variables increases, so too does the difficulty associated with debugging the preset function.

Is there a way to get a list (in common sense of the word, not necessarily the pd object sense) of all send symbols used in a patch and all of its subpatches? To get such a list in the context of the patch itself would be most useful, but even a trick outside of pd that would grab all of the names from the patch's source code would help.

Thanks in advance!
charlie

@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!

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

@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!!

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) ]

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!

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