Hey guys,
I'm writing a program that keeps track of what you've been working on and for how long. Does anyone know who I can force Pd to check firstly, whether pro tools is open, and secondly if it what is the name of the session being worked on?

I've been investigating using shell for this purpose, don't know if this is the right approach or not, but anyway haven't gotten anywhere in the last few days so I thought I'd ask the pros

-S

It might be an idea to have a look at the options for [window_name] http://tcl.tk/man/tcl8.4/TkCmd/wm.htm included in Pd Extended or you might be able to get something out of [wmangle] http://puredata.info/Members/thomas/wmangle

Wow thanks mate. Its scary how many objects there are out there that I don't know about, but exciting too. Fuck I love Pd

I think I might be a bit out of my depth here. From what I can see wmangle is a part of Flext, which is a library which is not included in PD-extended, and you must build it?

[window_name] on the other hand seems to be based around tck/tl, which is another thing entirely, and when it reports like this,

[window_name]
|
|
[symbol\

it gives back a reading starting with "x" e.g. x.7b4b10

So this got me onto reading about X windows, which I believe this is a part of?
Well at any rate there is at least a LOT to learn.

so far, i've found

[lsof -c Protools\
|
[shell]

useful. it's slow. but if you get junk coming out of the left outlet then you know Protools is open.

even though lsof's purpose is to list open files i think by the unix definition a file may not necessarily be documents since i haven't found any resemblance to files i've been working on.

maybe instead of going this route, you could search the midi serer for patterns of midi notes that you know are in each of the protools sessions?

Hmmm thats a very interesting idea with the midi. At work we have templates, a different one for each show. So one for the cop show one for the airport show etc. Because its post production though, we don't use midi. But what if I made a hidden midi track with a unique combination of notes and put it into each template... But then it still wouldn't tell you what session you were in, only what show you were on.

Such a shame that pdvst is in the graveyard, because I would have made it, then wrapped it to RTAS. Then I would have made a separate track with no output, called it "counter" and just popped the plugin onto it.

I spent some time with python today, ran through the first 6 tutorials online. I hear that Pd can execute python scripts, so I'll see where that takes me, both for this purpose and also for the general enjoyment of learning.

If only those bastards at Avid would give people the SDK to write plugins!

it's even better that there is no other midi going on. because now it's even easier.

one midi note per session... C0 = 1, D0 = 2, E0 = 4 e.t.c.

Why wouldn't this tell you what session you were in, only what show you were on?

Yes that is very true, as a stand alone solution it would be perfect. Unfortunately it would be impractical in this instance (I didn't explain this before) firstly because we go through about 250 sessions a week, but more importantly because one of the design constraints of this program is that it has to be "idiot" proof. If any given session can only be identified by a unique combination of midi notes, then even if the template has a combination of midi notes saying what show it is, the session will still need its own combination to indicate what episode it is. At which point you wind up back at manually entering data either to the time keeper program or as midi notes in each session.

I know (this is one of our current problems) that some of my colleagues simply cannot (or choose not to) switch on the time tracking software we currently have. So in a sense the flaw is not the tool itself, but that people fail to use it.

This is why having it be automatic (ie idiot proof) is so important, and hence why if it had been possible to make it as RTAS it would have been such an elegant solution.

Sorry for the long winded postings! I admit I am quite caught up in this project of my own making. Arif I want to express my appreciation for engaging with me over this problem also.

@arif said:

so far, i've found

even though lsof's purpose is to list open files i think by the unix definition a file may not necessarily be documents since i haven't found any resemblance to files i've been working on.

Ah yes now I understand what you are saying here. But now you have given me hope, as running,

lsof -c Preview

amongst all the other junk it spits back, does indeed also list
Preview 514 sergery txt REG 14,2 638283 390013 /Users/sergery/Documents/About Stacks.pdf

and I have this exact file open! So once I get to my protools rig and I'll test to see if I can parse the information down to just the ptf I'm working on.

great. post the results if you get any closer.

so close now.

lsof | grep WaveCache.wfm

returns

Pro\x20To 744 mark 46u REG 14,2 12672 4370889 /Users/mark/Documents/PRO TOOLS ON A LAPTOP/WaveCache.wfm

in terminal.

But its not working as a message to the shell in Pd...

I consider the possibility that | grep is not implemented in the Shell object for Pd. Sad for me, but if it is true I understand it, Shell must be a very full on object to write after all..

Edit: But that idea makes no sense at all- because all I'm doing is sending a message to the shell. The content of the message shouldn't matter should it? It just gets sent and whatever comes back comes back..