@chvolow24 said:

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

UDP is a dumb protocol: no handshaking, no confirmation of message receipt -- it's "I sent it out the port, then we just hope for the best."

Lack of handshaking means (AFAIK) UDP doesn't have a concept of sending back to the originating location. Because it's dumb, it's simpler: [netsend -u] only sends, [netreceive -u] only receives. The idea of passing a message into [netreceive] and it being sent somewhere doesn't make sense in UDP land.

In the helpfile, the "send back" functionality is demonstrated for TCP connections but not for UDP. I don't think this is a casual omission -- I think this actually reflects the functionality.

hjh

@ben.wes said:

actually, there has been quite some work on it in the recent months - including updates of the pd version (to 0.54 - so 0.55 is still due). the current builds on github are just 2 months old

Thanks, that's good to know. The other thread mentioned a much older source.

hjh

One thing I picked up from another thread here is that Purr Data is several Pd versions behind the main line (perhaps even a few years behind). If vstplugin~ depends on relatively recent functions, it might be incompatible with Pure Data. But I can't be more specific.

hjh

Which version / flavor of Pd? (Pure Data, or plugdata, or purr data... and version number.)

How did you install gem? (The answer to that question provides information about where gem is located in your filesystem, which is important for solving this problem.)

hjh

@raynovich No need, it was just a grumpy moment in the morning before coffee. Glad that I could point you in a good direction with the patch, no worries.

hjh

@raynovich said:

So part of my frustration as I read your initial help was that you did not include the '/' in you example:

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz. (See above)

I guess my thinking here was that xxx/yyy/zzz was meant to represent any path, including absolute paths -- the important thing about the example was the format of command, not the relative-ness of the path placeholder that I wrote.

I'll also say that I feel a bit like I'm getting criticized for omitting one character that would have been helpful. Which... nah. Sure, it was a mistake, but... I'll continue to post at times, and some of those posts will have errors.

So, I think my question about ofelia still "somewhat" pertains. Perhaps you know the answer?

Why does ofelia make unix commands include a backslash before the beginning of the path?

Whereas if ofelia was never opened it does not need the backslash?

I look at it this way. When you use relative paths, the behavior of your code depends on something outside of the control of your code: the current working directory. That's a risk factor: you might get away with it, or you might not. Whereas absolute paths are, well, absolute -- every absolute path leads to one and only one location -- so, no risk of cwd messing that up.

Clearly ofelia is changing the Pd process's working directory. That's a bit rude -- I'd assume that externals would try to minimize side effects outside of their own scope -- but if that's what it's doing, then you just have to avoid dependence on a specific cwd.

Or: "It works sometimes, so it should always work" is not always a realistic expectation. I think it's more realistic to think, "If it doesn't work sometimes, then it's not reliable, so find another way."

hjh

@raynovich said:

Thanks for the response. I still think cd is not working in shell or command. I am trying to do the same actions in terminal as shell and command.

My whole post was about why these objects are not the same as a terminal window.

You're programmatically generating the commands, so you can programmatically generate them with full paths, and not use cd.

Why "not use cd"? Because as you've already found, cd is unreliable with these objects. So you kinda have a couple of options here: 1/ complain, and not make progress; 2/ generate the commands in a way that avoids the failure point and is certain to work, and move forward today with your project.

E.g., to work just with the filename upstream, and concatenate the path only at the moment of building the command:

EDIT: Symbols needed to be tagged -- this patch works:

EDIT: Oops, the [t] object should be [t s b].

hjh

@raynovich said:

Does ofelia take over the "terminal" or some other function for Pure Data if created?

TL;DR Probably the best solution is for you to construct the commands with full paths, pointing exactly where you want, and do not rely on the current working directory.

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz.

Why?

"Shell" functions (as I understand it -- maybe it's different in some programming environments, but this is my observation) generally don't persist their state.

That is, if you open a terminal window, there is one shell, and every command operates on the same shell. cd changes the current working directory of the shell, and the next command remembers the new cwd.

An object like [shell] is like opening a new terminal window for every command. Every invocation starts from scratch. So you should not expect it to work if you ask shell to first cd, then ls. (You said this worked, but I was not able to get that behavior on my machine.)

SuperCollider has a couple of ways to do it that illustrate the issues involved.

"ls".unixCmd;  // user home

"cd tmp".unixCmd;  // no output, OK

"ls".unixCmd;  // still user home

The cd did not affect the second ls -- because it's like: terminal window 1, ls; terminal window 2, cd; terminal window 3, ls and why would you expect window 2 to affect the behavior of window 3?

Many shells, when parsing the typed input, can handle a series of commands separated by &&:

"cd tmp && ls".unixCmd;  // lists ~/tmp, OK!

But this is a parsing feature. If a backend issues the command in a different way -- as an array of strings, where the first string is the command and the other strings are arguments, one by one -- this bypasses the parser (because the arguments are already parsed into the array), and the && trick no longer works.

"cd tmp && ls".split($ ).postcs.unixCmd;
[ "cd", "tmp", "&&", "ls" ]
(and no `ls` listing)

[shell], as far as I can see, works in this second way. A message like ls tmp works only if it's a list of two symbols. If you try to make it a single command string -- ls\ tmp -- then it fails, because there is no system command named l-s-space-t-m-p. (In SC, "ls tmp".unixCmd runs the command through the shell's parser, which splits a string into command-and-argument. That usage isn't supported in [shell]. Maybe it's supported in [command] but I didn't take a look.)

hjh

@atux said:

is there any object that allows to do a melodic inversion?

For chromatic intervals, just use [-] -- like, if you want middle C to be the reflection point:

(your MIDI note)
|
[120 $1(
|
[-]

For diatonic intervals, you'd need to convert to a diatonic representation, then subtract, and convert back.

hjh

@lacuna said:

I am highly interested in how to sync or interface Reaper or other DAW with PD control rate sample-accurately intra-blocks.

The second part of this video is about my approach to that.

hjh