Mattijs

3) pick a second movie in the same folder and give it the name of the previous movie.

Mac OS 10.4.8, Max 4.6.2, Jitter 1.6.3 b2

Is this known behaviour?
1) read a movie in jit.qt.movie
2) rename the movie in finder
3) pick a second movie in the same folder and give it the name of the previous movie.
4) load the second movie in jit.qt.movie
5) the content doesn't change!

read-change-jit-qt-movie

It doesn't occur if I send the dispose message before reading:

Quote: Mattijs wrote on Thu, 03 May 2007 17:39

----------------------------------------------------

> 3) pick a second movie in the same folder and give it the name of the previous movie.

> 4) load the second movie in jit.qt.movie

> #P user jit.pwindow 54 137 82 62 0 1 0 0 1 0;

> #P newex 55 104 63 196617 jit.qt.movie;

> Mac OS 10.4.8, Max 4.6.2, Jitter 1.6.3 b2

Quote: Mattijs wrote on Thu, 03 May 2007 17:39
----------------------------------------------------
> Hi all,
>
> Is this known behaviour?
> 1) read a movie in jit.qt.movie
> 2) rename the movie in finder
> 3) pick a second movie in the same folder and give it the name of the previous movie.
> 4) load the second movie in jit.qt.movie
> 5) the content doesn't change!
>
> #P user jit.pwindow 54 137 82 62 0 1 0 0 1 0;
> #P toggle 55 44 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 55 62 52 196617 metro 40;
> #P message 67 83 30 196617 read;
> #P newex 55 104 63 196617 jit.qt.movie;
> #P connect 0 0 4 0;
> #P connect 3 0 2 0;
> #P connect 2 0 0 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 5;
>
> Is this intended behaviour?
>
> Mac OS 10.4.8, Max 4.6.2, Jitter 1.6.3 b2
>
>
> Mattijs
----------------------------------------------------


Whithout seeing the implementation jit.qt.movie, i'd suggest that this has

something to do with some internal buffering, or 'movie pooling'. It seems

as if, once a movie is read, a buffer is filled with the filepath as a key

and the low level clip position on disk as the key's value. So every time

you read a clip that's already read before and wasn't 'disposed', its

disk-location is read from the buffer and is not asked to the OS.

> It doesn't occur if I send the dispose message before reading:

> #P user jit.pwindow 103 214 82 62 0 1 0 0 1 0;

> #P newex 104 122 68 196617 prepend read;

> #P newex 104 172 97 196617 jit.qt.movie @vol 0;

> Quote: Mattijs wrote on Thu, 03 May 2007 17:39

> ----------------------------------------------------

> > 3) pick a second movie in the same folder and give it the name of the

> > 4) load the second movie in jit.qt.movie

> > #P user jit.pwindow 54 137 82 62 0 1 0 0 1 0;

Whithout seeing the implementation jit.qt.movie, i'd suggest that this has
something to do with some internal buffering, or 'movie pooling'. It seems
as if, once a movie is read, a buffer is filled with the filepath as a key
and the low level clip position on disk as the key's value. So every time
you read a clip that's already read before and wasn't 'disposed', its
disk-location is read from the buffer and is not asked to the OS.
...at least, i guess
:)

On 5/4/07, Mattijs Kneppers  wrote:
>
>
> This is really strange..
>
> It doesn't occur if I send the dispose message before reading:
>
> #P toggle 203 122 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 203 140 52 196617 metro 40;
> #P newex 104 99 27 196617 t l b;
> #P newex 121 144 50 196617 t dispose;
> #P user jit.pwindow 103 214 82 62 0 1 0 0 1 0;
> #P button 104 57 15 0;
> #P newex 104 122 68 196617 prepend read;
> #P newex 104 79 56 196617 opendialog;
> #P newex 104 172 97 196617 jit.qt.movie @vol 0;
> #P connect 6 0 2 0;
> #P connect 2 0 0 0;
> #P connect 8 0 7 0;
> #P connect 6 1 5 0;
> #P connect 0 0 4 0;
> #P connect 7 0 0 0;
> #P connect 5 0 0 0;
> #P connect 1 0 6 0;
> #P connect 3 0 1 0;
> #P window clipboard copycount 9;
>
> Can anyone explain this?
>
> Mattijs
>
>
> Quote: Mattijs wrote on Thu, 03 May 2007 17:39
> ----------------------------------------------------
> > Hi all,
> >
> > Is this known behaviour?
> > 1) read a movie in jit.qt.movie
> > 2) rename the movie in finder
> > 3) pick a second movie in the same folder and give it the name of the
> previous movie.
> > 4) load the second movie in jit.qt.movie
> > 5) the content doesn't change!
> >
> > #P user jit.pwindow 54 137 82 62 0 1 0 0 1 0;
> > #P toggle 55 44 15 0;
> > #P window setfont "Sans Serif" 9.;
> > #P window linecount 1;
> > #P newex 55 62 52 196617 metro 40;
> > #P message 67 83 30 196617 read;
> > #P newex 55 104 63 196617 jit.qt.movie;
> > #P connect 0 0 4 0;
> > #P connect 3 0 2 0;
> > #P connect 2 0 0 0;
> > #P connect 1 0 0 0;
> > #P window clipboard copycount 5;
> >
> > Is this intended behaviour?
> >
> > Mac OS 10.4.8, Max 4.6.2, Jitter 1.6.3 b2
> >
> >
> > Mattijs
> ----------------------------------------------------
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>

That's an interesting thought, mojo. I am curious if this behaviour is intended..

Another facet came up. If I send the dispose message before reading the new one, the content is updated. But when besides loading the movie in jit.qt.movie I also import the movie in a buffer~, the dispose message won't solve the problem anymore. And I can't find a 'dispose'-like command in buffer~ (clear doesn't do the job).

Is this all explained by mojo's guess? If so, would there be a way to reset this filepath key?

Quote: mojo wrote on Fri, 04 May 2007 17:47

> Whithout seeing the implementation jit.qt.movie, i'd suggest that this has

> something to do with some internal buffering, or 'movie pooling'. It seems

> as if, once a movie is read, a buffer is filled with the filepath as a key

> and the low level clip position on disk as the key's value. So every time

> you read a clip that's already read before and wasn't 'disposed', its

> disk-location is read from the buffer and is not asked to the OS.

> > It doesn't occur if I send the dispose message before reading:

> > #P newex 121 144 50 196617 t dispose;

> > #P user jit.pwindow 103 214 82 62 0 1 0 0 1 0;

> > #P newex 104 122 68 196617 prepend read;

> > #P newex 104 79 56 196617 opendialog;

> > #P newex 104 172 97 196617 jit.qt.movie @vol 0;

> > Quote: Mattijs wrote on Thu, 03 May 2007 17:39

> > ----------------------------------------------------

Quote: mojo wrote on Fri, 04 May 2007 17:47
----------------------------------------------------
> Whithout seeing the implementation jit.qt.movie, i'd suggest that this has
> something to do with some internal buffering, or 'movie pooling'. It seems
> as if, once a movie is read, a buffer is filled with the filepath as a key
> and the low level clip position on disk as the key's value. So every time
> you read a clip that's already read before and wasn't 'disposed', its
> disk-location is read from the buffer and is not asked to the OS.
> ...at least, i guess
> :)
>
>
> On 5/4/07, Mattijs Kneppers  wrote:
> >
> >
> > This is really strange..
> >
> > It doesn't occur if I send the dispose message before reading:
> >
> > #P toggle 203 122 15 0;
> > #P window setfont "Sans Serif" 9.;
> > #P window linecount 1;
> > #P newex 203 140 52 196617 metro 40;
> > #P newex 104 99 27 196617 t l b;
> > #P newex 121 144 50 196617 t dispose;
> > #P user jit.pwindow 103 214 82 62 0 1 0 0 1 0;
> > #P button 104 57 15 0;
> > #P newex 104 122 68 196617 prepend read;
> > #P newex 104 79 56 196617 opendialog;
> > #P newex 104 172 97 196617 jit.qt.movie @vol 0;
> > #P connect 6 0 2 0;
> > #P connect 2 0 0 0;
> > #P connect 8 0 7 0;
> > #P connect 6 1 5 0;
> > #P connect 0 0 4 0;
> > #P connect 7 0 0 0;
> > #P connect 5 0 0 0;
> > #P connect 1 0 6 0;
> > #P connect 3 0 1 0;
> > #P window clipboard copycount 9;
> >
> > Can anyone explain this?
> >
> > Mattijs
> >
> >
> > Quote: Mattijs wrote on Thu, 03 May 2007 17:39
> > ----------------------------------------------------
> > > Hi all,
> > >
> > > Is this known behaviour?
> > > 1) read a movie in jit.qt.movie
> > > 2) rename the movie in finder
> > > 3) pick a second movie in the same folder and give it the name of the
> > previous movie.
> > > 4) load the second movie in jit.qt.movie
> > > 5) the content doesn't change!
> > >
> > > #P user jit.pwindow 54 137 82 62 0 1 0 0 1 0;
> > > #P toggle 55 44 15 0;
> > > #P window setfont "Sans Serif" 9.;
> > > #P window linecount 1;
> > > #P newex 55 62 52 196617 metro 40;
> > > #P message 67 83 30 196617 read;
> > > #P newex 55 104 63 196617 jit.qt.movie;
> > > #P connect 0 0 4 0;
> > > #P connect 3 0 2 0;
> > > #P connect 2 0 0 0;
> > > #P connect 1 0 0 0;
> > > #P window clipboard copycount 5;
> > >
> > > Is this intended behaviour?
> > >
> > > Mac OS 10.4.8, Max 4.6.2, Jitter 1.6.3 b2
> > >
> > >
> > > Mattijs
> > ----------------------------------------------------
> >
> >
> > --
> > SmadSteck - http://www.smadsteck.nl
> > Hard- and software for interactive audiovisual sampling
> >
>
>
>
----------------------------------------------------


-> read -> change -> jit.qt.movie ?