@ddw_music said:

Lack of handshaking means (AFAIK) UDP doesn't have a concept of sending back to the originating location.

This actually isn't true. The first two bytes of a UDP datagram specify the source port, and the encapsulating IP packet includes the source address. A program receiving UDP messages with recvfrom, for example, can fairly easily send replies using the information populated in the struct pointed to by the src_addr argument. (I am also sending UDP messages to my main program from another program I wrote, which does receive the main program's replies).

@jameslo interesting, I did not know you could specify a return port! I don't think it solves the problem, unfortunately. If a return port is not specified, an ephemeral port will still be established by the client that can be used to receive responses. I can see with the help of lsof that this is indeed happening, and can confirm that my server is responding with messages to that port; the netsend just isn't acting on those messages as I expect it to (outputting them to the right outlet).

I expect [netsend -u] to write responses from the server to its right outlet, but it isn't working. I've confirmed that 1. the messages are received by the server, and 2. the server responds correctly (other applications can receive and print responses). lsof -P | grep UDP | grep pd shows that pd is indeed listening for a response.

What would prevent the responses from being received, output, or printed by netsend?

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!