Cycling 74 » Topic: -> read -> change -> jit.qt.movie ?

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

Mattijs — Thu, 03 May 2007 15:39:30 +0000

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

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

Mattijs — Fri, 04 May 2007 13:15:40 +0000

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
—————————————————-

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

mojo — Fri, 04 May 2007 15:47:26 +0000

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
>

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

Mattijs — Sat, 05 May 2007 08:37:57 +0000

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?

Mattijs

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
> >
>
>
>
—————————————————-