Re: [PD] [gemframebuffer] and [pix-film] ... weirdness

2018-03-03 Thread Jack
Hey Oliver,

Do you have a minimal patch with a shader that described your problem ?
It should be more easy to find a workaround if it exists but it seems
yours works perfectly.
++

Jack



Le 03/03/2018 à 12:23, oliver a écrit :
> Jack wrote:
>> Hello Oliver,
>>
>> As workaround you can put a [pix_separator] between the [t a a b] and
>> [pix_texture].
>> But yes, the bahavior is weird.
> 
> hi, jack !
> 
> thanks for your suggestion.
> 
> this "sort of" works, meaning that with one [gemframebuffer] this method
> does what you say.
> 
> if i am using more than one glsl shader in a row, each with a
> gemframebuffer, it doesn't work anymore.
> 
> anyway, my strange "[pix_image] after [pix_film]" method still does what
> i want so i will stick with that for the moment.
> 
> best
> 
> oliver
> 
> 
>> ++
>>
>> Jack
>>
>>
>>
>> Le 02/03/2018 à 01:33, oliver a écrit :
>>> hi, list !
>>>
>>> PD 0.48-0
>>> GEM 0.93.3
>>> WINDOWS 7 / 64bit
>>>
>>> i encountered a weird thing in GEM recently:
>>>
>>> when i use [gemframebuffer] with a still image (using [pix_image]) i can
>>> work with glsl shaders like shown in the GEM tutorials.
>>>
>>> however, i recently tried to do the same with a movie (using [pix_film],
>>> but only the first frame of the loaded film showed up ! subsequent
>>> "frame" messages did not work.
>>>
>>> by chance i found out that when i connected an empty [pix_image] object
>>> to [pix_film]'s left outlet, it suddenly DOES work as expected !
>>>
>>> is this the way it's supposed to be ?
>>>
>>> am i missing something ?
>>>
>>> or is this a windows thing again ?
>>>
>>>
>>>
>>> i attached a patch that demonstrates the problem
>>> (btw: using [pix_movie] instead of [pix_film] didn't change anything)
>>>
>>>
>>>
>>> thanks for any help
>>> (or deeper insight into [gemframebuffer]'s mysteries)
>>>
>>>
>>> best
>>>
>>> oliver
>>>
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
> 
> 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] [gemframebuffer] and [pix-film] ... weirdness

2018-03-03 Thread oliver

Jack wrote:

Hello Oliver,

As workaround you can put a [pix_separator] between the [t a a b] and
[pix_texture].
But yes, the bahavior is weird.


hi, jack !

thanks for your suggestion.

this "sort of" works, meaning that with one [gemframebuffer] this method 
does what you say.


if i am using more than one glsl shader in a row, each with a 
gemframebuffer, it doesn't work anymore.


anyway, my strange "[pix_image] after [pix_film]" method still does what 
i want so i will stick with that for the moment.


best

oliver



++

Jack



Le 02/03/2018 à 01:33, oliver a écrit :

hi, list !

PD 0.48-0
GEM 0.93.3
WINDOWS 7 / 64bit

i encountered a weird thing in GEM recently:

when i use [gemframebuffer] with a still image (using [pix_image]) i can
work with glsl shaders like shown in the GEM tutorials.

however, i recently tried to do the same with a movie (using [pix_film],
but only the first frame of the loaded film showed up ! subsequent
"frame" messages did not work.

by chance i found out that when i connected an empty [pix_image] object
to [pix_film]'s left outlet, it suddenly DOES work as expected !

is this the way it's supposed to be ?

am i missing something ?

or is this a windows thing again ?



i attached a patch that demonstrates the problem
(btw: using [pix_movie] instead of [pix_film] didn't change anything)



thanks for any help
(or deeper insight into [gemframebuffer]'s mysteries)


best

oliver



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




--

/// http://pendler.klingt.org //
\\\ http://oliver.klingt.org  \\


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list