Hello all,
I writing a patch that uses a simple shell Applescript app I made that closes a pdf file and opens a new pdf file in Preview mode on an Apple.

When the pd switches to the Applescript to close and then open pdfs, there is a digital click and pause in the smooth running of the program. Because this is obviously undesirable, I am wondering if I can do something to alleviate this problem.

Is it the Shell command?
Is it the nature of using Shell?
Is it that the computer leaves pd as the active window for a brief moment?
Is it that Preview is closed then opened again?

I can add the patch I created if that is needed to get to the bottom of this, but am wondering if there are any quick fixes to expand the dedication of the CPU to pd to avoid digital artifacts in performance.

@raynovich I am interested in a solution too, having the exact same behaviour on my setup (from pd linux opening ffplay via [shell]).

I coded a way back a python script using py/ext that was doing something very similar to shell, cannot remember if it was glitchy like shell...

@EEight @raynovich ...... maybe...."&" ?... https://unix.stackexchange.com/questions/103731/run-a-command-without-making-me-wait
David.

@EEight I tried that. It did not seem to work. Still working on it.

@whale-av Sadly not working.

What is happening (I think) is that the ggee/shell external is not using a thread, so executing a task is causing a glitch (not fast enough for the 64 buffersize).

I am looking at the code right now:
https://github.com/reduzent/pd-ggee/blob/master/control/shell.c

I could try to add a POSIX thread... but for now I can live with the glitch.

Unfortunately, I cannot live with the glitch in performance.

I have a new problem as well, but perhaps this should be put under a new heading. I was using Pd-0.47-1-64bit.

I recently downloaded Pd-0.48-0 and started using that version. I cannot seem to find where Pd-0.48-0 application is though on my computer. I can find the .47 version, but not .48.

Any ideas on what I am missing? How it is downloaded? Is it a "different" type of application. The icon is in my dock list.

@EEight @raynovich ... maybe sending messages to a second instance of Pd instructing that instance to send the shell messages?
David.

@whale-av Maybe I do not understand exactly what you are recommending.

Maybe I should explain what I am doing. I am working on a method for showing a musician music to perform in a pdf during performance. So, I have 9 pdfs of music notation. At points in pd, in which the musician should have a different pdf shown him or her, currently, I have the pd run a script through shell. The shell closes "Preview" (apple pdf reader), then open the new pdf in Preview. Finally, I reactivate pd so that the user can continue to input information to pd, via a foot pedal.

Now, I could easily just have the performer have a piece of music hard copy on a stand, but this is an exercise for future pieces I am hoping to work on.

Hope that makes sense,
William

@raynovich So you actually close Pd and re-open it? Is that what you mean by re-activate?
I was suggesting that you run a second instance of Pd that deals with the script (using a new separate copy of Pd with the [shell] object inside), hoping that the first instance (running audio) might be unaffected. The second instance, not running any audio, would receive instruction to run the script through netsend/netreceive (from the first).
If that is not possible in OSX maybe downloading a different version of Pd you could run one of each version at the same time.

If you open pdf's and close them manually does that cause clicks in Pd? I doubt that it would.
If it does then maybe they would all need to be open before you start, and just brought to the foreground by shell.
David.

No, not close and open pd.

The application that is active is the application that can receive data from the keyboard. I might not be saying that correctly, but hopefully that makes sense to you. So, when shell opens Preview, pd is in the background. If I tap one of the pedals, the information designated from the pedal does not go to pd. So, I have to make pd "active" or the front window on my mac.

If I ran another version of pd, I do not think that would work because I want pd to automatically open the pdfs. I could do that by hand, but the performer, me, has an instrument I am playing and could not also run the keyboard.

Does that make sense?

why not just display the pdf as images using Gem? don't know just an idea.

@raynovich Two patches talking in two separate instances (or versions) of Pd......maybe.zip
Although I don't know how you are making the Audio/pedal window active again.
Maybe run the [shell] instance of Pd with -nogui......?
Maybe send a [vis 1( message back to the main patch when the pdf has closed.
David.

@whale-av first of all, i just need to thank you for being so active in the pd community. You're always there to brainstorm and even send fully working patches, very generous.

What you are proposing is maybe doable, I will take the time to try it. The idea is to launch a [pd~] instance and hope that it will not drop audio in the main thread (the instance that send a message to [pd~]).

An alternative that comes to mind, is to use pdreceive executable. Never went this route, but I think it might just be a simple solution to this problem.

Cheers~

Thank you @EEight . It is a sad fact that trying to help out on this forum is the most fun in my life!
You are right, I think, about pdreceive, if it can be called and executed properly with shell. I have seen people have problems with that on this Forum.
Python seems often to be a simpler and a better solution.
I have never tried to program in Python, but it seems more predictable in its actions when "read" by a noob (slightly higher level language).
David.

the [shell] object starts a new process through the system scheduler I think so I believe it already has it's own thread (process)..

I would think that most of the glitches happen when you close and open Preview every time you need a new page..
Perhaps you could have all of the pages in a single pdf file with preview open, and when you need a new page perhaps there is a program with a "page down" scriptable event?

seems like you might be able to expose windows with applescript after enabling it for Preview
https://red-sweater.com/blog/150/minimal-scriptability
edit: you might be able to cobble something together through the system also
https://alvinalexander.com/macos/applescript-how-to-open-pdf-file-in-preview-go-to-page

@youaresound I am guessing/thinking that I really need to jump into Gem. I tried using it and became a bit discouraged. It was a bit unwieldy for what I wanted to do, but would most likely be the best way to do this.

@seb-harmonik.ar @whale-av @EEight @youaresound

Thank you all for you help with regards to my issue. I looked further into making applescripts and figured out how to manipulate the windows in a way that makes it so that I do not have to open and close Preview. It works quite well now.

I am guessing though that I really need to jump into GEM.

glad to hear you got it working. / for the future.

one way to go about this would be to convert pdf files to images using automator. then just load them into pix_image or pix_film. you can set the buffer to 1 so it only loads the image once (bang the gemhead once on each page/image load.)that way it doesn't keep rerendering the same image / (in the [gemhead] help file look at the buffering subpatch. )

david had a good suggestion about using separate instances of pd for each process.(audio video). but in this case might not be necessary.

in the help browser the files to check out are in the gem/examples/pix folder
01.image.pd
02.multiimage.pd
05.film.pd

you can create or destroy the gem window as needed.

I am trying to figure out how to activate GEM. Here is my Browser Help menu:

@raynovich https://forum.pdpatchrepo.info/topic/10980/gem-for-64-bit-osx/9 will get you there I think.
It is still unfinished business on 64-bit OSX, but it looks like it is getting better......
David.