list

i want to read a still image, but not display it immediately. instead 

i want to reveal blocks of it (maybe 10 x 10 pixels at a time) 

scanning from left to right, top to bottom, until the complete image 

and this needs to be quite fast too.. like maybe 30ms per block.

i want to read a still image, but not display it immediately. instead  
i want to reveal blocks of it (maybe 10 x 10 pixels at a time)  
scanning from left to right, top to bottom, until the complete image  
is visible.

no-subject-13

see tutorial 14, better look at 1-13 while youre there.

> whats the best way to do the following:

> i want to read a still image, but not display it immediately. instead i

> want to reveal blocks of it (maybe 10 x 10 pixels at a time) scanning from

> left to right, top to bottom, until the complete image is visible.

> and this needs to be quite fast too.. like maybe 30ms per block.

On Thu, Apr 17, 2008 at 11:07 AM,  wrote:

> hi
>
> whats the best way to do the following:
>
> i want to read a still image, but not display it immediately. instead i
> want to reveal blocks of it (maybe 10 x 10 pixels at a time) scanning from
> left to right, top to bottom, until the complete image is visible.
>
> and this needs to be quite fast too.. like maybe 30ms per block.
>
> thanks
> m
>
>
>
>

i read tutorial 14 and while i was the 1 to 13 too.

i still have problems getting it to be smooth. gonna use vvvv instead.

On 17 Apr 2008, at 09:21, yair reshef wrote:

> see tutorial 14, better look at 1-13 while youre there.

> On Thu, Apr 17, 2008 at 11:07 AM, wrote:

> i want to read a still image, but not display it immediately. 

> instead i want to reveal blocks of it (maybe 10 x 10 pixels at a 

> time) scanning from left to right, top to bottom, until the 

thanks
i read tutorial 14 and while i was the 1 to 13 too.
i still have problems getting it to be smooth. gonna use vvvv instead.
ta
m

> see tutorial 14, better look at 1-13 while youre there.
>
>
> On Thu, Apr 17, 2008 at 11:07 AM,  wrote:
> hi
>
> whats the best way to do the following:
>
> i want to read a still image, but not display it immediately.  
> instead i want to reveal blocks of it (maybe 10 x 10 pixels at a  
> time) scanning from left to right, top to bottom, until the  
> complete image is visible.
>
> and this needs to be quite fast too.. like maybe 30ms per block.
>
> thanks
> m
>
>
>
>

www.markfell.com
-----------------------


if you feel more comfortable doing it in vvvv, have fun.

do you have some comments about that environment i'd be glad to hear.

> i read tutorial 14 and while i was the 1 to 13 too.

> i still have problems getting it to be smooth. gonna use vvvv instead.

> On 17 Apr 2008, at 09:21, yair reshef wrote:

> > On Thu, Apr 17, 2008 at 11:07 AM, wrote:

> > whats the best way to do the following:

> > i want to read a still image, but not display it immediately. instead i

> > want to reveal blocks of it (maybe 10 x 10 pixels at a time) scanning from

> > left to right, top to bottom, until the complete image is visible.

> > and this needs to be quite fast too.. like maybe 30ms per block.

if you feel more comfortable doing it in vvvv, have fun.
do you have some comments about that environment i'd be glad to hear.
from anyone using that also.

On Sat, Apr 19, 2008 at 11:20 PM,  wrote:

> thanks
> i read tutorial 14 and while i was the 1 to 13 too.
> i still have problems getting it to be smooth. gonna use vvvv instead.
> ta
> m
>
>
> On 17 Apr 2008, at 09:21, yair reshef wrote:
>
>  see tutorial 14, better look at 1-13 while youre there.
> >
> >
> > On Thu, Apr 17, 2008 at 11:07 AM,  wrote:
> > hi
> >
> > whats the best way to do the following:
> >
> > i want to read a still image, but not display it immediately. instead i
> > want to reveal blocks of it (maybe 10 x 10 pixels at a time) scanning from
> > left to right, top to bottom, until the complete image is visible.
> >
> > and this needs to be quite fast too.. like maybe 30ms per block.
> >
> > thanks
> > m
> >
> >
> >
> >
> >
>
> www.markfell.com
> -----------------------
>
>
>
>
>

thanks Andreas for the report from the front.

i looked into vvvv 3 years ago when i was just starting with jitter, it

many of the good things has been there from the start, a testemnt to the

its true that jitter lacks in the multiple department, and reactivity has

always been a weakness of visual programing languages. in that department v4

lacks support for 3rd party languages like jitter with c, java, js and my

i feel 4v has been born with spreads in mind while jitter is more of a tool

for single object manipulation, leaving multiple as an afterthought. as you

mentioned, geared for working in a column not in row. most of the work and

demos has a single object end-point in mind. the tutorials and cookbooks

leans more thowrds video processing and less "many abstract shapes"

aesthetics. which is quit abundant with v4 and p5(~realtime).

many times the tool draws users with similar aesthetic tastes.

as we could see with the community's response to Andrew b. examples of

tinyVideo and latter, the demand for better spread support is here, and

right now its the work of creative patching that makes it possible. the

methods are available but hard to implement and not for the weak of heart.

I'm sure latter versions of jitter will address this.

the "live patching" issue is already around the corner with max5 new

inspektor(sic) and live debug inlets. some of this method were open to

veterans but now they will be were they should. at the forefront.

as many others, im excited about max5 (ad jitter2) and i hope for us all v4

will continue to capture hearts and prosper.

my 2cent, would love to hear more. and excuse my crappy grammar and

On Sun, Apr 20, 2008 at 6:08 PM, Andreas Wetterberg <

> Hi yair (and sorry everyone if I messed up the threading here...)

> I have just switched part of my Jitter work to vvvv, pending a further

> vvvv and spreads outperform jit.gl.multiple for my needs, and the openGL

renders better on my system. Thousands and thousands of vertices at full

framerate, and my main problem in Jitter OpenGL (the overlapping and

> - but the main thing is the ease of patching; I can do "blind patching",

like I would do in Max, and string together large arrays of openGL objects

moving in concert. I particularly like NOT having to do matrices for this

kind of stuff - these are pieced together with spreads. One thing that

appears a bit "weaker" in vvvv is the Particles objects, but that is brand

> Another thing that really integrates beautifully is shaders: Just type in

"PhongDirectional" and you'll get beautiful lighting and shading in an

instant. Just gels better with me right now. Patching is so much faster for

me - I did a full wiimote-draws-hundreds-of-dancing-3d-shapes-on-screen

patch in like an hour yesterday. Love that.

> So, at least for the time being, I will connect maxMSP/Jitter to vvvv via

OSC, and do my matrix processing in Jitter.

> if you feel more comfortable doing it in vvvv, have fun.

> do you have some comments about that environment i'd be glad to hear.

> On Sat, Apr 19, 2008 at 11:20 PM, wrote:

> > i read tutorial 14 and while i was the 1 to 13 too.

> > i still have problems getting it to be smooth. gonna use vvvv instead.

thanks Andreas for the report from the front.
i looked into vvvv 3 years ago when i was just starting with jitter, it
wasnt were its at now.
many of the good things has been there from the start, a testemnt to the
deep thought that went into it.

its true that jitter lacks in the multiple department, and reactivity has
always been a weakness of visual programing languages. in that department v4
lacks support for 3rd party languages like jitter with c, java, js and my
favorite jit.lua. a plus here.

i feel 4v has been born with spreads in mind while jitter is more of a tool
for single object manipulation, leaving multiple as an afterthought. as you
mentioned, geared for working in a column not in row. most of the work and
demos has a single object end-point in mind. the tutorials and cookbooks
leans more thowrds video processing and less "many abstract shapes"
aesthetics. which is quit abundant with v4 and p5(~realtime).
many times the tool draws users with similar aesthetic tastes.

as we could see with the community's response to Andrew b. examples of
tinyVideo and latter, the demand for better spread support is here, and
right now its the work of creative patching that makes it possible. the
methods are available but hard to implement and not for the weak of heart.
I'm sure latter versions of jitter will address this.

the "live patching" issue is already around the corner with max5 new
inspektor(sic) and live debug inlets. some of this method were open to
veterans but now they will be were they should. at the forefront.

as many others, im excited about max5 (ad jitter2) and i hope for us all v4
will continue to capture hearts and prosper.

my 2cent, would love to hear more.  and excuse my crappy grammar and
editing..

On Sun, Apr 20, 2008 at 6:08 PM, Andreas Wetterberg <
awetterberg@post.cybercity.dk> wrote:
>
> Hi yair (and sorry everyone if I messed up the threading here...)
> About vvvv:
> I have just switched part of my Jitter work to vvvv, pending a further
investigation of it all.
>
> Preliminary conclusion of mine:
> vvvv and spreads outperform jit.gl.multiple for my needs, and the openGL
renders better on my system. Thousands and thousands of vertices at full
framerate, and my main problem in Jitter OpenGL (the overlapping and
"flickering" of planes) doesn't exist in
>
> - but the main thing is the ease of patching; I can do "blind patching",
like I would do in Max, and string together large arrays of openGL objects
moving in concert. I particularly like NOT having to do matrices for this
kind of stuff - these are pieced together with spreads. One thing that
appears a bit "weaker" in vvvv is the Particles objects, but that is brand
new and might receive revisions soon.
>
> Another thing that really integrates beautifully is shaders: Just type in
"PhongDirectional" and you'll get beautiful lighting and shading in an
instant. Just gels better with me right now. Patching is so much faster for
me - I did a full wiimote-draws-hundreds-of-dancing-3d-shapes-on-screen
patch in like an hour yesterday. Love that.
>
> So, at least for the time being, I will connect maxMSP/Jitter to vvvv via
OSC, and do my matrix processing in Jitter.
>
> Andreas
>
> yair reshef skrev:
> if you feel more comfortable doing it in vvvv, have fun.
> do you have some comments about that environment i'd be glad to hear.
> from anyone using that also.
>
>
> On Sat, Apr 19, 2008 at 11:20 PM,  wrote:
>
> > thanks
> > i read tutorial 14 and while i was the 1 to 13 too.
> > i still have problems getting it to be smooth. gonna use vvvv instead.
> > ta
> > m
>
>
>
>

second paragraph should read 'recursivity' and not 'reactivity'. blame the

On Sun, Apr 20, 2008 at 7:57 PM, yair reshef wrote:

> thanks Andreas for the report from the front.

> i looked into vvvv 3 years ago when i was just starting with jitter, it

> many of the good things has been there from the start, a testemnt to the

> its true that jitter lacks in the multiple department, and reactivity has

> always been a weakness of visual programing languages. in that department v4

> lacks support for 3rd party languages like jitter with c, java, js and my

> i feel 4v has been born with spreads in mind while jitter is more of a

> tool for single object manipulation, leaving multiple as an afterthought. as

> you mentioned, geared for working in a column not in row. most of the work

> and demos has a single object end-point in mind. the tutorials and cookbooks

> leans more thowrds video processing and less "many abstract shapes"

> aesthetics. which is quit abundant with v4 and p5(~realtime).

> many times the tool draws users with similar aesthetic tastes.

> as we could see with the community's response to Andrew b. examples of

> tinyVideo and latter, the demand for better spread support is here, and

> right now its the work of creative patching that makes it possible. the

> methods are available but hard to implement and not for the weak of heart.

> I'm sure latter versions of jitter will address this.

> the "live patching" issue is already around the corner with max5 new

> inspektor(sic) and live debug inlets. some of this method were open to

> veterans but now they will be were they should. at the forefront.

> as many others, im excited about max5 (ad jitter2) and i hope for us all

> v4 will continue to capture hearts and prosper.

> my 2cent, would love to hear more. and excuse my crappy grammar and

> On Sun, Apr 20, 2008 at 6:08 PM, Andreas Wetterberg <

> > Hi yair (and sorry everyone if I messed up the threading here...)

> > I have just switched part of my Jitter work to vvvv, pending a further

> > vvvv and spreads outperform jit.gl.multiple for my needs, and the openGL

> renders better on my system. Thousands and thousands of vertices at full

second paragraph should read 'recursivity' and not 'reactivity'. blame the
spellchecker.

On Sun, Apr 20, 2008 at 7:57 PM, yair reshef  wrote:

> thanks Andreas for the report from the front.
> i looked into vvvv 3 years ago when i was just starting with jitter, it
> wasnt were its at now.
> many of the good things has been there from the start, a testemnt to the
> deep thought that went into it.
>
> its true that jitter lacks in the multiple department, and reactivity has
> always been a weakness of visual programing languages. in that department v4
> lacks support for 3rd party languages like jitter with c, java, js and my
> favorite jit.lua. a plus here.
>
> i feel 4v has been born with spreads in mind while jitter is more of a
> tool for single object manipulation, leaving multiple as an afterthought. as
> you mentioned, geared for working in a column not in row. most of the work
> and demos has a single object end-point in mind. the tutorials and cookbooks
> leans more thowrds video processing and less "many abstract shapes"
> aesthetics. which is quit abundant with v4 and p5(~realtime).
> many times the tool draws users with similar aesthetic tastes.
>
> as we could see with the community's response to Andrew b. examples of
> tinyVideo and latter, the demand for better spread support is here, and
> right now its the work of creative patching that makes it possible. the
> methods are available but hard to implement and not for the weak of heart.
> I'm sure latter versions of jitter will address this.
>
> the "live patching" issue is already around the corner with max5 new
> inspektor(sic) and live debug inlets. some of this method were open to
> veterans but now they will be were they should. at the forefront.
>
> as many others, im excited about max5 (ad jitter2) and i hope for us all
> v4 will continue to capture hearts and prosper.
>
> my 2cent, would love to hear more.  and excuse my crappy grammar and
> editing..
>
>
>
>
>
> On Sun, Apr 20, 2008 at 6:08 PM, Andreas Wetterberg <
> awetterberg@post.cybercity.dk> wrote:
> >
> > Hi yair (and sorry everyone if I messed up the threading here...)
> > About vvvv:
> > I have just switched part of my Jitter work to vvvv, pending a further
> investigation of it all.
> >
> > Preliminary conclusion of mine:
> > vvvv and spreads outperform jit.gl.multiple for my needs, and the openGL
> renders better on my system. Thousands and thousands of vertices at full
> framerate, and my main problem in Jitter OpenGL (the overlapping and
> "flickering" of planes) doesn't exist in
> >
> > - but the main thing is the ease of patching; I can do "blind patching",
> like I would do in Max, and string together large arrays of openGL objects
> moving in concert. I particularly like NOT having to do matrices for this
> kind of stuff - these are pieced together with spreads. One thing that
> appears a bit "weaker" in vvvv is the Particles objects, but that is brand
> new and might receive revisions soon.
> >
> > Another thing that really integrates beautifully is shaders: Just type
> in "PhongDirectional" and you'll get beautiful lighting and shading in an
> instant. Just gels better with me right now. Patching is so much faster for
> me - I did a full wiimote-draws-hundreds-of-dancing-3d-shapes-on-screen
> patch in like an hour yesterday. Love that.
> >
> > So, at least for the time being, I will connect maxMSP/Jitter to vvvv
> via OSC, and do my matrix processing in Jitter.
> >
> > Andreas
> >
> > yair reshef skrev:
> > if you feel more comfortable doing it in vvvv, have fun.
> > do you have some comments about that environment i'd be glad to hear.
> > from anyone using that also.
> >
> >
> > On Sat, Apr 19, 2008 at 11:20 PM,  wrote:
> >
> > > thanks
> > > i read tutorial 14 and while i was the 1 to 13 too.
> > > i still have problems getting it to be smooth. gonna use vvvv instead.
> > > ta
> > > m
> >
> >
> >
> >
>
>

(no subject)