[PD] video midi

[Michael Droettboom]

First let me explain (and perhaps apologize in advance) that part of my
motivation for this project was just to see if it could be done, and for
the thrill of doing it.  So my "abandoning" of GEM may have been
premature.  However, looking back I do feel there are some differences
about my system that I like, though other's opinions may differ.

On Fri, 15 Jun 2001, guenter geiger wrote:
> On Thu, 14 Jun 2001, Michael Droettboom wrote:
> > TECHNICAL DETAIL:
> > My overall architecture is to pass video data as if they were very large
> > blocks of audio data between objects.  My video_in_rgb object, for
> > instance, outputs three data streams, one for red, green and blue.
>
> All of this sounds great, I do have one question though.
> Why did you choose to implement your own data processing concept, instead
> of using the pix objects from gem ?

Well, in a sense, I didn't really implement my own -- I'm using Pd's.  But
I do see your point.

> Image data is inherently different from audio data, therefore the gain you
> have from being able to reuse the pd signal processing objects (which are
> optimized for audio calculations) doesn't seem to be worth it.

I don't agree that image data is inherently different from audio data.
It's only in the interpretation that they're different.

The most basic objects -- the ones that are useful to both audio and video
processing -- such as +~ and *~ are not optimised for audio calculations.
They're simply optimised for floats.

> Or put the other way, what was it that you didn't like about them
> GEM way ?

My only complaint (and it's more of a preference) is that GEM pix objects
support multiple types of video data (RGB and grey).  I feel it adds a
good deal of flexibility to a system when all the data streams are
essentially the same and completely interchangable.  In hindsight, I could
get such behaviour from GEM by simply writing deinterleave and interleave
objects (I couldn't find any, but I may be missing something.)

All my objects are fairly well modularized, and having just now revisited
the GEM source code, it shouldn't be too much work to wrap them in the pix
style.

-- 
Michael Droettboom
mdboom at peabody.jhu.edu
410.625.7596

Computer Music Research
Peabody Conservatory of Music
Johns Hopkins University