• oid

    @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].
    Untitled.png
    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.

    posted in technical issues read more
  • oid

    @atux If it does not need to be the literal cursor you could fake a cursor. I just used a unicode arrow as the label for a white canvas and send it some movements I recorded with [iemguts/receivecanvas]. This way you can just use pd's own mouse movement and click messages in tandem with the fake cursor. Possible nice side effect is no collisions between programmed input and user input, you can always return the real cursor to where the user last left it.
    cursor.pd

    posted in technical issues read more
  • oid

    @atux Using [command] and xdotool would be easiest but will not be portable, but it will work on linux and maybe bsd/osx as well. You will likely need to install xdotool but that is easy enough and it is a very easy program to use. The trick will be that unless it is a full screen window or rigidly fixed in place you will also have to get window position and calculate the absolute position of the number boxes since I do not think xdotool knows about windows, xprop or xwininfo should do the trick for window position. Don't have time for a detailed response with a patch right now but the helpfile for [command] and a couple google searches on xdotool/xprop/xwininfo or their man pages should get you your answers.

    posted in technical issues read more
  • oid

    @cfry same way as you would in terminal, specify the full path name with the filename, so instead of log.txt it would be something like home/cfry/pd/log-recs/log.txt.

    posted in technical issues read more
  • oid

    @gentleclockdivider It was serious, just attempting to nudge your brain over to the answer you suggested and how to test it. That would print 0-800 to the console which would tell you if the console log is running out since 0 would get bumped out of the log if its max is 799. More simply you can open your patch, send a bang to a print and see if the earliest entry ends up being 226 instead of 225 or throw together a quick patch to test it with an [until] and a counter.

    posted in technical issues read more
  • oid

    @gentleclockdivider Consider it more a hint than a literal suggestion but if you are the sort who enjoys both counting and clicking have at it, the method is sound.
    Untitled.png

    posted in technical issues read more
  • oid

    @gentleclockdivider if we convert the numbers to a keycode, build a list and then convert them back to numbers it will work.
    Untitled.png
    Forgot something, you need an [f] after the [list tosymbol] to convert it back to a number or it will be a symbol that looks like a number.

    posted in technical issues read more
  • oid

    @gentleclockdivider They both use add2 and addcomma, I just automated it and made it agnostic of the size of the list. It is not as complex as it looks.
    Untitled2.png
    A more transparent example of my previous version but less general.
    Untitled3.png

    posted in technical issues read more
  • oid

    @gentleclockdivider Use [list prepend] -> [list trim] to automate things for arbitrary list lengths. Check the help for msg->changing messages for more details and methods.
    Untitled.png

    posted in technical issues read more
  • oid

    @lacuna said:

    Still a mystery why the send-method works? Anyone knows?

    You mean mine with the symbols in the list? As I understand it the only time symbols go into the symbol hash table is when they are lone symbols not attached to any other data structure, they are stored in the heap and the hash table has pointers to the memory location. If the symbol is part of an object which allocates its own place in memory (list, text) it never goes to the hash table. In this case pd just passes around the pointer to the position of the symbol in the list's allocated memory so never needs to search the hash table.

    Drowning in symbols is referring to how pd gets slow at finding symbols in the hash table if the number of symbols gets high, big hash table more time spent trying to find the right symbol. My above assumptions regarding symbols and list/text not going into the hash table are based off of pd not choking on symbols when you load large text files into a [text]. I mostly posted that patch to see if anyone could clarify on how pd really works here. On modern devices the symbol count can get very high before issues arrive, can't remember the last time I hit the wall here and the only times I have hit the wall was way back when before I knew about the hash table stuff.

    I think [send] will be the most efficient as long as symbol count does not cause issues. I believe you could also speed up your spigot version a tiny amount by changing the three [t a b] to [t a a] to avoid the type conversion, messages don't care what triggers them so no need to do the conversion.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!