Improving Squeak's Multimedia - Part 2

Brad Fuller brad at sonaural.com
Tue Feb 22 20:35:40 UTC 2005


Hi All,

 

Fantastic, we have several people who are interested and I hope willing 
to play a part in improving Squeak's Multimedia capabilities:

 

Blake (Blake: what's your last name?)

Dean Swan

Craig Latta

Russell Penney

Steve Elkins

Martin Kuball

Yoshiki Ohshima

Mark McCahill

Juan Vuletich

Cornelius Huber

Brad Fuller

 

I hope I didn't misspell or miss someone. If so, apologies.

 

Let me start off the discussion by asking some hi-level questions. And, 
by all means, please chime in. I present only one slanted POV --- your 
views will be valuable to provide a robust analysis of the situation.

 

=== Multimedia Definition

 

Maybe the first order of business is to achieve agreement on what we 
mean by "Multimedia".

I looked it up after Martin's email and he's right - multimedia includes 
a variety of media such as the real-time areas (e.g. film/video, music) 
as well as static media (e.g. text, graphics.)

 

Russell provided another interesting POV that containers could hold a 
multitude of multimedia assets. and that these basic frameworks could 
provide easy re-use.

 

My 2cents: I was only thinking of "real-time" assets such as audio, 
music, video, etc.

 

What are your thoughts on the definition of Multimedia?

 

 

=== Hi Level Interests?

 

Furthermore, our definition of Multimedia may be a clear superset of 
what we want to tackle. For instance, it might turn out that we have 
just enough hands, or interest, to look at the audio classes; or maybe 
just video; or maybe the majority is only interested in adding MPEG4 to 
Squeak.

 

For me, I'm obviously interested in only audio and video. I know this is 
broad, but I just want to get the top level issues out of the way. As an 
example of elimination, I am not interested in graphics or text.

 

What are your interests?

 

 

==== Attack Plan

 

Finally, I propose that we decide on what to tackle and how to do it.

 From a bird's eye view, we might look at 3 distinct phases (not 
necessarily linear in order - can be approached simultaneously):

 

    * Review/Discuss/Plan/Fix existing classes (which hopefully fix
      existing tools/apps)
    * Discuss-Design/Plan/Enhance existing classes
    * Discuss-Design/Plan/Add new capabilities: new classes, tools and
      end-user applications.

(That's a lot, right there.)


I'm willing to put in time, at the very least, toward fixing and 
enhancing the audio/music side of MM. I'm also interested in helping to 
test and use any video functionality - especially audio-video 
synchronization issues. Lastly, I would like to begin discussing new 
real-time capabilities for Squeak -- sort of plan while we get the house 
in order (the discussions might circumvent fixes, who knows.)

 

What areas interest you?


And, are you interested in helping?

 

===== Is This A Team?

 

Finally, Finally,

In light of the current squeak-dev traffic: Does this look like a team 
to propose? It seems orthogonal to the team proposals from the castaways.


What do you think about MM as a team? Is it a sub-team?
How does the rest of the Squeak community feel?

 

 

brad


BTW: Are there any related on-going projects that should be incorporated?

 




More information about the Squeak-dev mailing list