Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38307 > unrolled thread

Monitoring updating directory for image for GUI

Back to article view | Back to comp.lang.python

Contents

  Monitoring updating directory for image for GUI ciscorucinski@gmail.com - 2013-02-06 14:02 -0800
    Re: Monitoring updating directory for image for GUI Chris Angelico <rosuav@gmail.com> - 2013-02-07 17:25 +1100
      Re: Monitoring updating directory for image for GUI ciscorucinski@gmail.com - 2013-02-07 16:48 -0800
        Re: Monitoring updating directory for image for GUI Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-08 02:01 +0000
          Re: Monitoring updating directory for image for GUI ciscorucinski@gmail.com - 2013-02-08 09:09 -0800
            Re: Monitoring updating directory for image for GUI Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-09 00:53 +0000
            Re: Monitoring updating directory for image for GUI Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-08 20:32 -0500
          Re: Monitoring updating directory for image for GUI ciscorucinski@gmail.com - 2013-02-08 09:09 -0800
      Re: Monitoring updating directory for image for GUI ciscorucinski@gmail.com - 2013-02-07 16:48 -0800
    Re: Monitoring updating directory for image for GUI Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-02-07 11:25 +0100
    Re: Monitoring updating directory for image for GUI Piet van Oostrum <piet@vanoostrum.org> - 2013-02-07 18:11 +0100
    Re: Monitoring updating directory for image for GUI ciscorucinski@gmail.com - 2013-02-11 14:50 -0800
      Re: Monitoring updating directory for image for GUI MRAB <python@mrabarnett.plus.com> - 2013-02-11 23:50 +0000
      Re: Monitoring updating directory for image for GUI Piet van Oostrum <piet@vanoostrum.org> - 2013-02-13 17:09 +0100

#38307 — Monitoring updating directory for image for GUI

Hello,

I have been using Python for a few months now, so I am still learning a few things here and there.

Basically I am creating a program that will stream musical notes into a program called Lilypond one-by-one and it will create the sheet music for that stream of music via OS command. Your understanding of Lilypond is not needed, but you need to know that for each new note that is streamed in "real-time", a PNG image file will be created for that stream of music up to that point...via Lilypond.

What I am looking at doing is to monitor the directory where the image files are being created in real-time, and update the GUI (build with gtk.Builder and Glade) with the most recent image file. I have the program multithreaded and it appears that all of the images are being created sequentially; however, I need to make sure that an older image (an image with less notes displayed) is NOT going to be displayed over a newer image.

The question I have is what do you see as the best way of going about this? 

I have looked at creating a Stack from the python List, along with os.walk(). However, I am not sure if those are adequate with a directory that is actively adding new files. Also, how I imagined using the Stack with taking the next item off of the stack meant that older ones would be replacing new ones...and with a queue, it might be updating too slow; especially if the notes being streamed in are played fast. So I would like for the most recent image to be used and all others discarded.

Thanks,
Christopher

[toc] | [next] | [standalone]

#38333

On Thu, Feb 7, 2013 at 9:02 AM,  <ciscorucinski@gmail.com> wrote:
> Basically I am creating a program that will stream musical notes into a program called Lilypond one-by-one and it will create the sheet music for that stream of music via OS command. Your understanding of Lilypond is not needed, but you need to know that for each new note that is streamed in "real-time", a PNG image file will be created for that stream of music up to that point...via Lilypond.

I'm surprised nobody has yet responded to this. The list's usually a
lot quicker, heh...

Side point: How real-time can you actually run Lilypond? It usually
takes a bit of time to render a sheet of music. But leaving that
aside.

> What I am looking at doing is to monitor the directory where the image files are being created in real-time, and update the GUI (build with gtk.Builder and Glade) with the most recent image file. I have the program multithreaded and it appears that all of the images are being created sequentially; however, I need to make sure that an older image (an image with less notes displayed) is NOT going to be displayed over a newer image.
>
> The question I have is what do you see as the best way of going about this?

Not sure I fully understand the problem here. Tell me if this workflow
is correct:

* Note comes in
* Lilypond is spawned asynchronously to render the new state
* A new file is created, with a unique name
* Your program shows the latest of these files, no more and no less

Or do you need to sometimes show multiple files?

Can you make use of sequential file naming to ensure that you can
always find the latest file? That way, you just make sure you never
overwrite a displayed image whose name is > than the one you now have.

ChrisA

[toc] | [prev] | [next] | [standalone]

#38386

Real-time...as close to real-time as possible. That is why I did not really want to use a queue. That is because if a bunch of the thread that create the images finish really close to one another (when they should be spread out based on how the music is played), then there would be a larger "lag" in the display. So displaying only the most recent image is preferred. 

That is why I though Stack...but then that might mean that older images will replace newer ones.

The Workflow is as such:

1) Music is analyzed and streamed to the program. Note-by-Note.
2) The note is grabbed (same way as a Java Scanner class)
3) A new thread is created to call an OS command (Lilypond command)
   a) Thread waits until command is finished, and Lilypond creates an image that I can define the filename for in a directory.

From here I want only the latest one (as close to the latest one at least) to be displayed to the gtkImage object in the GUI

I set up a class that would act as a directory monitor (just stubbed)...that would do all the work I am asking for here

Also, don't think this matters much, but I am using Windows (I seen someone mention Linux)

[toc] | [prev] | [next] | [standalone]

#38393

On 8 February 2013 00:48,  <ciscorucinski@gmail.com> wrote:
> Real-time...as close to real-time as possible. That is why I did not really want to use a queue. That is because if a bunch of the thread that create the images finish really close to one another (when they should be spread out based on how the music is played), then there would be a larger "lag" in the display. So displaying only the most recent image is preferred.

Who/what are you responding to here? You haven't included any context
from what you're replying to.

> That is why I though Stack...but then that might mean that older images will replace newer ones.
>
> The Workflow is as such:
>
> 1) Music is analyzed and streamed to the program. Note-by-Note.
> 2) The note is grabbed (same way as a Java Scanner class)
> 3) A new thread is created to call an OS command (Lilypond command)
>    a) Thread waits until command is finished, and Lilypond creates an image that I can define the filename for in a directory.
>
> From here I want only the latest one (as close to the latest one at least) to be displayed to the gtkImage object in the GUI

So you have a thread that updates the image and then checks the stack
to see if a new image is available? Can you not just have it only try
to load the newest image?

You say that you control the filenames of the images. I assume that
you are notified when a file is created and given the filename of the
new file. So you can maintain a mapping of filename->ordering. In this
case you can determine when a file notification arrives whether the
filename corresponds to a more recent note than the filename that is
currently waiting to be displayed (or is currently displayed). If it
is an older note then discard it (and delete the file?) when the
notification arrives. If it is newer then discard the one that is
currently waiting to be displayed. This way there are always either
zero or one filenames waiting and if there is one then it is the most
recent one seen so far.

> I set up a class that would act as a directory monitor (just stubbed)...that would do all the work I am asking for here

Is that using something like watchdog?
http://pypi.python.org/pypi/watchdog

>
> Also, don't think this matters much, but I am using Windows (I seen someone mention Linux)

It matters for how you monitor the directory at least.


Oscar

[toc] | [prev] | [next] | [standalone]

#38464

> Who/what are you responding to here? You haven't included any context
> from what you're replying to.

Sorry, never really used Google Groups, or anything like this before. That I was responding to only Chris Angelico with his question of how real-time it needed to be...since it takes some time for Lilypond to create the images.


> So you have a thread that updates the image and then checks the stack
> to see if a new image is available? Can you not just have it only try
> to load the newest image?

That is what I am trying to figure out how to do. I have a counter that updates with every note that is grabbed from the stream. That counter is passed into a threaded class that might or might not create the image right away...but seems to create them sequentially from what I have seen so far (I don't know if that is absolute thought). 

Please let me know you thought on the above part! Each new thread should only take only a very small amount longer to do than the previous thread that was started...because it has one more note to deal with this time.

Anyways...I do have the count of the latest image that WILL BE created...but by the time that one is created in the directory, a new note is most likely streamed in and replaces that count. Therefore, I cannot really do that...I think.

hmmmm, I wonder. I create the images via OS command that will .wait() on a subprocess.Popen(). I could increment the counter there? Or do something there that will let me know of the most recent image file via a counter or something? But it needs to be thread-safe

> You say that you control the filenames of the images. I assume that
> you are notified when a file is created and given the filename of the
> new file. So you can maintain a mapping of filename->ordering. In this
> case you can determine when a file notification arrives whether the
> filename corresponds to a more recent note than the filename that is
> currently waiting to be displayed (or is currently displayed). If it
> is an older note then discard it (and delete the file?) when the
> notification arrives. If it is newer then discard the one that is
> currently waiting to be displayed. This way there are always either
> zero or one filenames waiting and if there is one then it is the most
> recent one seen so far.

I am not notified when the file is created...but like I said before, I wait on the subprocess and could do something there.

> Is that using something like watchdog?
> http://pypi.python.org/pypi/watchdog

I don't know about Watchdog...but from an earlier version of a tutorial online...

http://pypi.python.org/pypi/watchdog/0.3.6  (Yes, it is currently on v0.6.0 and this is older - v0.3.6)

... it looks like I COULD do something like...

class MyEventHandler(FileSystemEventHandler):
    ...
    ...
    def on_created(self, event):
        # update gtkImage object here!!

...right? Or no? I will say that I kind of like that. The only thing is, do you think that would "flicker" in the GUI if a bunch of new images are created in quick succession? Anyways, I think that would be the most desired outcome...with every image being used and replaced with something newer without a large lag...as it will happen during each creation of a new image. 


> It matters for how you monitor the directory at least.

My other question, if I do monitor the directory vs. use a queue, or stack / list, is how to monitor a directory that is actively being updated while I search for the file. This might not matter and something like os.walk() might work...I don't know, I don't know python that well yet.

Do you get what I mean with this?


Sorry if something seems out of place...I was going back and forth and adding / removing things to my reply.

Thanks,
Christopher

[toc] | [prev] | [next] | [standalone]

#38485

 On 8 February 2013 17:09,  <ciscorucinski@gmail.com> wrote:
>> So you have a thread that updates the image and then checks the stack
>> to see if a new image is available? Can you not just have it only try
>> to load the newest image?
>
> That is what I am trying to figure out how to do. I have a counter that updates with every note that is grabbed from the stream. That counter is passed into a threaded class that might or might not create the image right away...but seems to create them sequentially from what I have seen so far (I don't know if that is absolute thought).
>
> Please let me know you thought on the above part! Each new thread should only take only a very small amount longer to do than the previous thread that was started...because it has one more note to deal with this time.

Are you creating a new thread for each new note? I imagined that you
would have 3 threads: producer, organiser and consumer. It looks like
this:

# Producer:
for x in produce_music():
    counter += 1
    create_note_file(filename)
    notes_map[filename] = counter

# Organiser
def on_file_notify(filename):
    if notes_map[filename] > notes_map[waiting]:
        waiting = filename

# Consumer
while True:
    if waiting is not None:
        display(waiting)
        waiting = None
    else:
       sleep()

[SNIP]
>
> I am not notified when the file is created...but like I said before, I wait on the subprocess and could do something there.

I don't understand your setup.

>
>> Is that using something like watchdog?
>> http://pypi.python.org/pypi/watchdog
>
> I don't know about Watchdog...but from an earlier version of a tutorial online...
>
> http://pypi.python.org/pypi/watchdog/0.3.6  (Yes, it is currently on v0.6.0 and this is older - v0.3.6)
>
> ... it looks like I COULD do something like...

I haven't actually used watchdog myself. I was just querying how you
were getting updates about file changes (and suggesting to use a PyPI
package since at least one was available for your needs).


Oscar

[toc] | [prev] | [next] | [standalone]

#38489

On Fri, 8 Feb 2013 09:09:31 -0800 (PST), ciscorucinski@gmail.com
declaimed the following in gmane.comp.python.general:

> 
> That is what I am trying to figure out how to do. I have a counter that updates with every note that is grabbed from the stream. That counter is passed into a threaded class that might or might not create the image right away...but seems to create them sequentially from what I have seen so far (I don't know if that is absolute thought). 
> 
> Please let me know you thought on the above part! Each new thread should only take only a very small amount longer to do than the previous thread that was started...because it has one more note to deal with this time.
> 
> Anyways...I do have the count of the latest image that WILL BE created...but by the time that one is created in the directory, a new note is most likely streamed in and replaces that count. Therefore, I cannot really do that...I think.
> 
> hmmmm, I wonder. I create the images via OS command that will .wait() on a subprocess.Popen(). I could increment the counter there? Or do something there that will let me know of the most recent image file via a counter or something? But it needs to be thread-safe
>

	One problem I see is a race condition. Unless you have some sort of
completion flag from the program generating the images you can't rely on
the "newest" file in the directory being a complete image.

	So... You either run one image behind if just looking at directory
contents (on the basis the newest image file is still being written); or
you have to run lock-step with the image generator, where it signals
when <file-n> is available.

	If monitoring a directory for changes, and you are on Windows, I
believe there is a native Win32 API to catch changes to directories.
{I'm still waiting for Windows Internals Part 2 to arrive -- though this
series is closer to the old VMS "black book" than to a reference manual
for Windows system calls}

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365261%28v=vs.85%29.aspx

	You still have the chase condition unless you code a two level
change... 

	displayFile = None
	inWorkFile = None
	while True:
		#wait for change notification of new file (ignore times, etc.)
		displayFile = inWorkFile
		inWorkFile = #whatever the change notification reported
		if displayFile:
			#do something with completed file

... and that leaves the matter of handling the last file when you
conclude there will be no more updates.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#38465

> Who/what are you responding to here? You haven't included any context
> from what you're replying to.

Sorry, never really used Google Groups, or anything like this before. That I was responding to only Chris Angelico with his question of how real-time it needed to be...since it takes some time for Lilypond to create the images.


> So you have a thread that updates the image and then checks the stack
> to see if a new image is available? Can you not just have it only try
> to load the newest image?

That is what I am trying to figure out how to do. I have a counter that updates with every note that is grabbed from the stream. That counter is passed into a threaded class that might or might not create the image right away...but seems to create them sequentially from what I have seen so far (I don't know if that is absolute thought). 

Please let me know you thought on the above part! Each new thread should only take only a very small amount longer to do than the previous thread that was started...because it has one more note to deal with this time.

Anyways...I do have the count of the latest image that WILL BE created...but by the time that one is created in the directory, a new note is most likely streamed in and replaces that count. Therefore, I cannot really do that...I think.

hmmmm, I wonder. I create the images via OS command that will .wait() on a subprocess.Popen(). I could increment the counter there? Or do something there that will let me know of the most recent image file via a counter or something? But it needs to be thread-safe

> You say that you control the filenames of the images. I assume that
> you are notified when a file is created and given the filename of the
> new file. So you can maintain a mapping of filename->ordering. In this
> case you can determine when a file notification arrives whether the
> filename corresponds to a more recent note than the filename that is
> currently waiting to be displayed (or is currently displayed). If it
> is an older note then discard it (and delete the file?) when the
> notification arrives. If it is newer then discard the one that is
> currently waiting to be displayed. This way there are always either
> zero or one filenames waiting and if there is one then it is the most
> recent one seen so far.

I am not notified when the file is created...but like I said before, I wait on the subprocess and could do something there.

> Is that using something like watchdog?
> http://pypi.python.org/pypi/watchdog

I don't know about Watchdog...but from an earlier version of a tutorial online...

http://pypi.python.org/pypi/watchdog/0.3.6  (Yes, it is currently on v0.6.0 and this is older - v0.3.6)

... it looks like I COULD do something like...

class MyEventHandler(FileSystemEventHandler):
    ...
    ...
    def on_created(self, event):
        # update gtkImage object here!!

...right? Or no? I will say that I kind of like that. The only thing is, do you think that would "flicker" in the GUI if a bunch of new images are created in quick succession? Anyways, I think that would be the most desired outcome...with every image being used and replaced with something newer without a large lag...as it will happen during each creation of a new image. 


> It matters for how you monitor the directory at least.

My other question, if I do monitor the directory vs. use a queue, or stack / list, is how to monitor a directory that is actively being updated while I search for the file. This might not matter and something like os.walk() might work...I don't know, I don't know python that well yet.

Do you get what I mean with this?


Sorry if something seems out of place...I was going back and forth and adding / removing things to my reply.

Thanks,
Christopher

[toc] | [prev] | [next] | [standalone]

#38387

Real-time...as close to real-time as possible. That is why I did not really want to use a queue. That is because if a bunch of the thread that create the images finish really close to one another (when they should be spread out based on how the music is played), then there would be a larger "lag" in the display. So displaying only the most recent image is preferred. 

That is why I though Stack...but then that might mean that older images will replace newer ones.

The Workflow is as such:

1) Music is analyzed and streamed to the program. Note-by-Note.
2) The note is grabbed (same way as a Java Scanner class)
3) A new thread is created to call an OS command (Lilypond command)
   a) Thread waits until command is finished, and Lilypond creates an image that I can define the filename for in a directory.

>From here I want only the latest one (as close to the latest one at least) to be displayed to the gtkImage object in the GUI

I set up a class that would act as a directory monitor (just stubbed)...that would do all the work I am asking for here

Also, don't think this matters much, but I am using Windows (I seen someone mention Linux)

[toc] | [prev] | [next] | [standalone]

#38342

ciscorucinski@gmail.com writes:

> Basically I am creating a program that will stream musical notes into
> a program called Lilypond one-by-one and it will create the sheet
> music for that stream of music via OS command. Your understanding of
> Lilypond is not needed, but you need to know that for each new note
> that is streamed in "real-time", a PNG image file will be created for
> that stream of music up to that point...via Lilypond.
>
> What I am looking at doing is to monitor the directory where the image
> files are being created in real-time, and update the GUI (build with
> gtk.Builder and Glade) with the most recent image file. I have the
> program multithreaded and it appears that all of the images are being
> created sequentially; however, I need to make sure that an older image
> (an image with less notes displayed) is NOT going to be displayed over
> a newer image.

The "canonical" way to monitor file system changes (in Linux) is to use
inotify. There is a python wrapper, at
https://github.com/seb-m/pyinotify

But it would be much simpler to have Lilypond (or a wrapper) write out
the name of the files it produces (e.g., to a fifo) and have your GUI to
synchronize on that.

> I have looked at creating a Stack from the python List, along with
> os.walk(). However, I am not sure if those are adequate with a
> directory that is actively adding new files. Also, how I imagined
> using the Stack with taking the next item off of the stack meant that
> older ones would be replacing new ones...and with a queue, it might be
> updating too slow; especially if the notes being streamed in are
> played fast. So I would like for the most recent image to be used and
> all others discarded.

I'm  lost.

-- Alain.

[toc] | [prev] | [next] | [standalone]

#38357

ciscorucinski@gmail.com writes:

> Hello,
>
> I have been using Python for a few months now, so I am still learning a few things here and there.
>
> Basically I am creating a program that will stream musical notes into a program called Lilypond one-by-one and it will create the sheet music for that stream of music via OS command. Your understanding of Lilypond is not needed, but you need to know that for each new note that is streamed in "real-time", a PNG image file will be created for that stream of music up to that point...via Lilypond.
>
> What I am looking at doing is to monitor the directory where the image files are being created in real-time, and update the GUI (build with gtk.Builder and Glade) with the most recent image file. I have the program multithreaded and it appears that all of the images are being created sequentially; however, I need to make sure that an older image (an image with less notes displayed) is NOT going to be displayed over a newer image.
>
> The question I have is what do you see as the best way of going about this? 
>
> I have looked at creating a Stack from the python List, along with os.walk(). However, I am not sure if those are adequate with a directory that is actively adding new files. Also, how I imagined using the Stack with taking the next item off of the stack meant that older ones would be replacing new ones...and with a queue, it might be updating too slow; especially if the notes being streamed in are played fast. So I would like for the most recent image to be used and all others discarded.
>
I suppose you have two threads, one for producing the music by calling
Lilypond, and one for displaying the generated images. Because it is
multithreaded you should use a Queue from the module
Queue(Python2)/queue(Python3) to communicate between the threads.

Producing thread:
  send note to Lilypond
  wait until PNG file is generated (Lilypond completed)
  Q.put(filename)

Displaying thread:
  while True:
    fn = Q.get() # this will block until a filename is available
    # now check if there is more in the queue
    while True:
      try:
        fn = Q.get_nowait
        # here we got a newer one
      except Empty:
        break # stop the inner loop
    display the image in fn.

In this way you always display the most recent one.
You can make it more sophisticated by removing files that have been
displayed and files that you skip.

-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

#38708

WOW...I am thinking that all of this was actually unnecessary, I don't think I need a Queue, or List / Stack, or any traversal of the file system to accomplish this!!

I only need one image displayed at a time and don't care about them after a newer image is generated. So my prototype of just replacing the image over and over again SHOULD suffice. All I need the for the "monitor" now is to grab the image file (that might have or might not have been updated by Lilypond) at set amount of times and refresh the GtkImage object.

The only reason why I originally suggested using multiple files was because I wanted to make sure that I had to most recent image and I was not sure if the threads would guarantee that. So my only remaining question (for now) is...

I'm I guaranteed that if I have threads 1...n, that were all started in **quick** succession to call an OS command on Lilypond, that if I replaced the image file being generated with the completion of each thread that I would end up with the final image being from thread n...and that if I were able to update the GUI in a fast enough fashion, that I would see the images being displayed on the screen from 1 to n without anything being out of place?

All of my tests have shown that seems to be a reasonable assumption, but I need to know for sure. If that was the case were I am not guaranteed that, then when a user decides to stop the stream I could resend the note stream that I have saved on my end to Lilypond one last time to guarantee that all of the notes are displayed.


So I would only create one image location at "images\sheetMusic.png" and that file would be continuously updated as new notes are streamed in. My "monitor" class (might be a legacy component now) would basically look for that one image - "images\sheetMusic.png", grab it, and update the GUI at an interval that is easy on the eyes (maybe a half second for example).

Could there be a problem where the image is being updated, so the OS deletes the image, and my program tries to update the image but cannot find it, and the OS reassigns that file location to that previous file location and name?

Let me know what you thing or if anything is confusing you.
Thanks for the comments so far!

 - Christopher - 

[toc] | [prev] | [next] | [standalone]

#38710

On 2013-02-11 22:50, ciscorucinski@gmail.com wrote:
[snip]
>
> So I would only create one image location at "images\sheetMusic.png"
> and that file would be continuously updated as new notes are streamed
> in. My "monitor" class (might be a legacy component now) would
> basically look for that one image - "images\sheetMusic.png", grab it,
> and update the GUI at an interval that is easy on the eyes (maybe a
> half second for example).
>
> Could there be a problem where the image is being updated, so the OS
> deletes the image, and my program tries to update the image but
> cannot find it, and the OS reassigns that file location to that
> previous file location and name?
>
[snip]
You could create the image under one name and then copy or move/rename
it for display.

[toc] | [prev] | [next] | [standalone]

#38818

ciscorucinski@gmail.com writes:

> WOW...I am thinking that all of this was actually unnecessary, I don't think I need a Queue, or List / Stack, or any traversal of the file system to accomplish this!!
>
> I only need one image displayed at a time and don't care about them
> after a newer image is generated. So my prototype of just replacing
> the image over and over again SHOULD suffice. All I need the for the
> "monitor" now is to grab the image file (that might have or might not
> have been updated by Lilypond) at set amount of times and refresh the
> GtkImage object.
>
> The only reason why I originally suggested using multiple files was
> because I wanted to make sure that I had to most recent image and I
> was not sure if the threads would guarantee that. So my only remaining
> question (for now) is...
>
> I'm I guaranteed that if I have threads 1...n, that were all started
> in **quick** succession to call an OS command on Lilypond, that if I
> replaced the image file being generated with the completion of each
> thread that I would end up with the final image being from thread
> n...and that if I were able to update the GUI in a fast enough
> fashion, that I would see the images being displayed on the screen
> from 1 to n without anything being out of place?

No, I don't think so. You have no guarantee that the images will be
completed in the same order as the threads are started.

> All of my tests have shown that seems to be a reasonable assumption,
> but I need to know for sure. If that was the case were I am not
> guaranteed that, then when a user decides to stop the stream I could
> resend the note stream that I have saved on my end to Lilypond one
> last time to guarantee that all of the notes are displayed.
>
>
> So I would only create one image location at "images\sheetMusic.png"
> and that file would be continuously updated as new notes are streamed
> in. My "monitor" class (might be a legacy component now) would
> basically look for that one image - "images\sheetMusic.png", grab it,
> and update the GUI at an interval that is easy on the eyes (maybe a
> half second for example).
>
It could very well be that the image is being constructed and therefore does not yet contain a complete image when you want to display it.

> Could there be a problem where the image is being updated, so the OS
> deletes the image, and my program tries to update the image but cannot
> find it, and the OS reassigns that file location to that previous file
> location and name?

Maybe it can find it, but it might not be a valid image
>
> Let me know what you thing or if anything is confusing you.
> Thanks for the comments so far!

I think the way I described it in my previous message  still gives you the easiest solution:
I'll repeat it here in case you missed it.

I suppose you have two threads, one for producing the music by calling
Lilypond, and one for displaying the generated images. Because it is
multithreaded you should use a Queue from the module
Queue(Python2)/queue(Python3) to communicate between the threads.

Producing thread:
  send note to Lilypond
  wait until PNG file is generated (Lilypond completed)
  Q.put(filename)

Displaying thread:
  while True:
    fn = Q.get() # this will block until a filename is available
    # now check if there is more in the queue
    while True:
      try:
        fn = Q.get_nowait
        # here we got a newer one
      except Empty:
        break # stop the inner loop
    display the image in fn.

In this way you always display the most recent one.
You can make it more sophisticated by removing files that have been
displayed and files that you skip.

-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web