@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

@lacuna said:

click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).

Yes, this is how I was hoping it would work, but it's not always the case that [bang~] bangs after the spigot is open within the same control block. It appears to bang afterward if there is a direct bang from a GUI element, but bangs before if the bang came from a delay. (Edit: I'm going to start a new topic on this, I don't see why this should be true)
bang~ runs last.pd
bang~ runs first.pd
If it runs before, then we are really waiting until it bangs at the end of the next audio block. (BTW, you can modify the number of blocks of delay and see the numbers change as you'd expect)

You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries.

Yes, but all I'm concluding from that is that the message is available in the control block before the audio block that contains its actual time. The fact that so many Pd objects ignore the fractional block of time remaining suggests to me that it could be possible to truncate that fractional block of time in the message in order to make objects like vline~ start at the beginning of the audio block, like sig~.

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block?

Your diagram annotation is correct, but "want" is a strong word . Let's just say I'm curious if it's possible. Right now, I'm delaying things like [sig~] to match [vline~] by inserting [vline~] just before them. I could have used any of our 3 quantizers to align the first [vline~] ramp with the block following the block that contains the fractional block timed message, but then I would have had to also delay my [sig~] processing a block as @seb-harmonik-ar confirmed.

The last two slides in that PP deck you linked to shows what I mean. Objects like [vline~] implement the ideal, but I'm wondering how to make it behave more like the last slide. See how the message's timing is labeled "t0+16"? Wouldn't it be possible just to zero out the "16" part?

@flextUser just stumbled on my old tcl files with notes about adding menus and menu items so here they are if you still need them. Just the basic Tk menu commands work, I could have sworn pd required you to jump through some hoops.

add new menu:

.menubar insert <index> command -label <label> -command {<command>}

add new menu item to an existing menu:

.menubar.<menu> insert <index> command -label <label> -command {<command>}

Edit: And the popup menu.

set old_args [info args ::pdtk_canvas::create_popup]
set old_body [info body ::pdtk_canvas::create_popup]
rename ::pdtk_canvas::create_popup ""

append old_body {$popupid add command -label <label>}

proc ::pdtk_canvas::create_popup "$old_args" "$old_body"
unset old_args
unset old_body

If memory serves the roundabout way here was because there were some headaches with getting the proper $popupid value so exploiting the everything is a string nature of Tcl was the easier path. Not sure if that was because of my ignorance or actually the case.

@ddw_music It might not be a bug. Objects should never have the same name but that seems to be how it is.
Plugdata has loaded the vanilla [line~] object, but has picked up the object reference for [cyclone/line~] when it searched for the help file, simply because it found it first? The help files are not built in to the Pd binary. If they were then the problem would not arise, or more likely be reversed and cyclone help would never be found.
But the real problem is the use of the same object name.
Anyway, the author has already spotted this thread and submitted a bug report.

@gentleclockdivider You probably know, but if you set the Pd command window to at least log level 2 (normal) you will see where Pd has searched for an object or a help file. Maybe that is not the same for plugdata, but if it is then you will see all the directories that were searched when looking for the help.
As you discovered, as [line~] is "built-in" to the Pd single binary no search is performed, and the vanilla [line~] will always be loaded unless as you say the cyclone library has been specified.

As you have also found....... [cyclone/line~] does accept a maximum of 128 natoms.......... https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/audio/line.c#L179
.... but as a long list (no commas). It works out separation of the pairs by the odd and even atoms in the list.

So is it possible that it was it [cyclone/line~] that you tested in your opening post? .... as you separated the pairs in that screenshot?
You can tell by the right outlet...... but the help message hides where it could be in the screenshot?
It might be worth your time to find out what search paths are operating for your different forks of Pd.
I wonder whether some of them are sharing playlist files or preferences in the registry.
David.

@atux Your terminal example has the &&, second command will not be run unless the first command returns zero. In pd you just execute each command without care if the first has completed, delay gives enough time for it to complete. Generally if I need to do compound commands like these I either put them into scripts and just execute the scripts instead so the shell can handle it all or I use multiple instances of [command].

Scripts are easy and reliable but it is not all right there easy to work with and see in the patch. Multiple instances of [command] gives a bit more flexibility since we can use the output of each individually and well as run it into the next {command].

For your problem, is it always consistent? certain apps always display the behavior or is it a sometimes things? Does it work from the terminal in this case? Have you tried having it click twice? xev could be of help, it will provide a good test window for your mouse manipulation since all it does is print those events to terminal.

Xnee is another program you might find useful for your project, it can record and playback mouse/keyboard events, might be more suitable for your needs than xdotool depending on what you are doing.

Hey, this is fun!

My needs are slightly different in that I usually can't tell when a voice is going to become free to be allocated again, so I make it the voice's responsibility to tell me when it's available. Voices also have to figure out when to retrigger, which happens during voice stealing but also when commands are routed back to the voice that's currently handling a previous instance. Here's pseudo code for my allocator:

next command is issued
has it already been assigned a voice?
  yes:  send next command to that same voice
  no:  are there free voices?
    yes:  record that that command is being handled by that voice
          note the order that that voice was allocated
          send next command to that voice
    no:  find the oldest allocated voice
         record that that command is being handled by that voice
         note the order that that voice was (re)allocated
         send next command to that voice

when a voice becomes free
  add it back into the list of available voices
  clear whatever command it was previously associated with
  clear whatever order that it was last allocated

And then inside each voice:

next command comes in
what state are we in?
  stopped:  trigger the action, go to running state
  running:  retrigger the action
  
when the action is finished, go to stopped state and tell the allocator you are available

resourceAllocator.zip

@cfry The simple hack to make this work on both in linux and OSX.
logger4.pd
Not completely sure the output of uname on OSX will be Darwin, if it does not work open up a terminal and run uname, what ever the output is is what you want to be the symbol in the [route]. And make sure to fix that path. You can also shorten that [del 1000], should be able to be dropped to at least 100.

The one fault with this is that killall tee is not great, it is possible there could be some other instance of tee running somewhere else and killall does kill all within the users permissions. OSX's paranoia might save you here, pd may not be able to kill apps which it did not start, depends on how they set things up. It is fairly safe as long as you do run pd as root and do not start any scripts running before sending that bang. Personally I would not worry about it until it bit me, I abuse killall to save having to get pids and it has only bitten me a few times in 20 years and never on something as innocuous as tee. If you are feeling paranoid or curious you can run tee in a terminal and then bang that right inlet to see if it kills the instance running in the terminal. We can make this safe with a few more [command]s if you want, need to rework a command like ps -f | grep "tee -a <log file name>" into playing well with [command], grab the pid and then run kill on that pid,

@zigmhount said:

TL;DR: Is it more efficient to [text search], [text get] and [text set] 91 times in one [text] object, or to [text get] and [text set] 1 time in each of 91 [text] objects? or in 91 [list] objects?

Going back to the original question...

In the source code, the function that locates a line by number is text_nthline(). This implements a linear search from the beginning of the text buffer, counting character by character, until it's crossed n newlines (semicolons or commas).

So performance will depend on how many lines, and how long the lines are.

Accessing lines near the end will be slower than accessing lines near the beginning.

For a linear search, you would predict that the time is proportional to the size. I built a benchmark where the lines are all roughly the same size, comparing 10 lines vs 100, 1000 and 10000, doing a million random accesses for each one.

23-0826-text-performance.pd

The smaller buffers are a bit slower than "linear" would predict, but this is probably because of function call overhead and can't be avoided. (x1000 vs x10000 is linear.)

Still, if you're wondering how a single text buffer of ~100 lines would do... 100 ms for 1,000,000 queries is pretty fast. So... don't worry about it...?

Or you could run this yourself on the lower-end laptop that you mentioned. (But... before you do... go into the [pd 1000000_queries] subpatch and change the 1e+06 message box to, say, 10000 or 100000. Otherwise you might be sitting there a while. And be sure to init the buffers first, should be clear where to click.)

I didn't benchmark the performance of accessing multiple separate text objects. Based on the source code, if you access line 0, then text_nthlne() will scan only the one line (to determine the endpoint). I don't know what is the overhead of switching a [text get] between buffers.

Honestly I think the Pd GUI stuff will be a heavier drain on CPU than either [text] approach.

hjh

How can I make it open the patch in the already running pd instance?

I use terminal a lot in my workflow, and usually launch things from terminal (I use 'lf' which is a terminal file explorer). Is there any trick to make xdg-open acknowledge an already running instance?

heres the pure data desktop file da xdg-open uses to handle .pd files:

[Desktop Entry]
Name=Pure Data (Pd)
Exec=pd-gui %F
Categories=Audio;AudioVideo;Development;Music;Graphics
Keywords=Audio;Video;Programming;Synthesis;Analysis
Comment=Visual dataflow programming platform for multimedia
Comment[ca]=Plataforma de programació visual per aplicacions multimèdia
Comment[de]=Grafische Datenflussprogrammierung für Multimedia
Comment[es]=Plataforma de programación visual para aplicaciones multimedia
Comment[fr]=Plateforme de programmation visuelle pour applications multimédia
Comment[it]=Piattaforma di programmazione visuale per applicazioni multimedia
Comment[pt]=Plataforma de programação visuais para multimedia
MimeType=text/x-puredata;
GenericName=Dataflow IDE
Type=Application
Terminal=false
Icon=puredata

I know this is unix related, I even tried asking in unix stack exchange but pure data seems to be alien to them:

https://unix.stackexchange.com/questions/752495/open-file-from-terminal-in-already-running-pure-data-instance?noredirect=1#comment1431905_752495

I am trying to make this work, but am struggling.

Here is the message I am sending:

find [object_name] [number 0f object created to delete]

but I am getting this message:

consistency check failed: sys_decodedialog: Cage_varIII_circle
(Tcl) INVALID COMMAND NAME: invalid command name ".find.searchin"
while executing
".find.searchin configure -text "$infostring""
(procedure "pdtk_showfindresult" line 19)
invoked from withi

heck failed: sys_decodedialog: Cage_varIII_circle
(Tcl) INVALID COMMAND NAME: invalid command name ".find.searchin"
while executing
".find.searchin configure -text "$infostring""
(procedure "pdtk_showfindresult" line 19)
invoked from within
"pdtk_showfindresult .x10044c780 1 1 42"
("uplevel" body line 11)
invoked from within
"uplevel #0 $docmds"bad

heck failed: sys_decodedialog: Cage_varIII_circle
(Tcl) INVALID COMMAND NAME: invalid command name ".find.searchin"
while executing
".find.searchin configure -text "$infostring""
(procedure "pdtk_showfindresult" line 19)
invoked from within
"pdtk_showfindresult .x10044c780 1 1 42"
("uplevel" body line 11)
invoked from within
"uplevel #0 $docmds"bad