@oid said:

Did you ever try using the full path to pdreceive as mentioned above,

Sweet, It works with the full path! I thought I tried it several times, hmm. And no error code. The right "error" outlet does send out listening on 3000 but it works anyhow.

I changed permissions: chmod a+rwx pdreceive but still didn't work without full path.

then I did this and noticed the com.apple.quarantine flag:

jnl@nmbp bin % ls -@l pdreceive
-rwxrwxrwx@ 1 jnl  admin  174048  3 Jul 18:11 pdreceive
    com.apple.lastuseddate#PS       16 
    com.apple.quarantine        57 
jnl@nmbp bin % xattr -d com.apple.quarantine pdreceive 
jnl@nmbp bin % ls -@l pdreceive                       
-rwxrwxrwx@ 1 jnl  admin  174048  3 Jul 18:11 pdreceive
    com.apple.lastuseddate#PS       16 
jnl@nmbp bin % 

The com.apple.quarantine flag is added on downloaded apps by osx, preventing them to run without confirmation.

Removed the flag but it still does not work. I have to read up a bit on osx security. Its close though.

@oid said:

But there could be an Applications directory in root for apps available to all users these days, once again my lack of knowledge regarding modern OSX.

that's how it is structured nowadays yes.

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

@oid

Cool! [route Darwin] worked but I had to put back the [delay 100] from [logger2] in order to have the [set exec...( update before [t b b b b b] hits the rest.

I noticed that you can actually skip using [netsend] and just go straight into your [list prepend send] ---> [command] part. How would this do performance wise? Is [netsend] more effective than [command] or would it not matter?

@cfry lol, tunnel vision, got so focused on solving the random problems and missed the obvious solution to all of them. Tee will do everything you need here and be slightly more efficient, the netsend/receive and pdsend/receive ways I would suspect more accurate to timing since it does not really matter when tee completes something as long as it does complete it and does it perfectly. So a final version?
logger-sane.pd

@oid a version of logger-sane.pd above of this ended up in an installation, and it seems to have worked pretty good, I still have not have had time to look at the last data recorded but it seems to be solid. The only bugger is that if you try to quit Pd with logger/[console] still running Pd will freeze. So if you accidentally hit cmd+q you will loose all edits since last save. But that is only a problem when working with it, not when it is installed and running. So thanks a lot for all the input, it has been a great help. When I get the chance I will start to experiment with using the data to dynamically change the synthesis configuration of the system.

Cheers

@cfry Didn't we figure out the cause of the freeze? Don't remember and don't feel like rereading the thread right now. Simple fix is to just unbind command+q or have a [loadbang] send [dirty 1( to the canvas so pd asks you if you want to save before quitting as a gentle reminder.

@oid no we didn't since it was assumed that I would put the project on a raspberrypi and this error seemed to be mac osx specific. It turned out that I used a macmini in the end because my (other) code was bloated and I did not have the time to clean it up and be efficient enough for my raspberrypi. Eventually it will be transferred to a rpi.

But I am curious about that [loadbang] to [dirty 1( to canvas. Never heard of it, how does it work?

@cfry Dirty 1 is pd's internal message saying the canvas has been altered so if you send that message when the patch is loaded pd will think the canvas has been changed even if it hasn't. It will not prevent you from just hitting enter and saving the patch allowing pd to quit and freeze but it might be enough to remind you that you need to kill tee before quiting. First version only works with recent versions of pd, not sure how new it has to be since it is another one of those features they forgot to mention and never put in the change log, I think it needs 54 but I don't really know, second version works quite a ways back.

You can also try [iemguts/closebang], stick it in the abstraction and have it trigger the killall tee but that may not work and we may have already explored that, don't remember.

@cfry @oid You can still send the perf message to Pd (in windows... others IDK)....
[;
pd perf 1(
will pop a "really quit?" message for all patch windows and the console, regardless of whether they have been edited.
It used to be (Pd extended) explicitly available from the Pd menu (performance mode), but now it is one of many hidden "features"..
pd perf 0 will turn it off.
David.

@oid how can I change the save directory of [command]? I would like to have all log recordings in a folder (log-recs).
I tried with the new [file cwd] object but that doesn't seem to work.

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