Improving Squeak's Multimedia - Part 2 Followup

Brad Fuller brad at sonaural.com
Fri Feb 25 16:30:43 UTC 2005


Thanks for the reply Russell. See below

Russell Penney wrote:

> Brad,
>
>    I am seeing a lot of synergy actually. You do the audio tidy up, 
> Blake does tools and doco, Dean does some very cool low level stuff 
> which I sure forms the basis of a bunch of later work (i.e. better 
> algorithms for OGG, etc than straight ports of "C"), Yoshiki, Martin 
> and others do video, I handle file formats (with lots of help :) and 
> the others test.
>
>  
>
> The main things I see happening from here that we need to resolve ASAP 
> are a bunch of questions.
>
> What do people see as the interfaces?
>
> What have others seen in a multimedia framework? Is there a good one 
> we can steal, I mean be influenced by.
>
> What are the lowest common denominators?
>
> What functionality does everyone want?
>
I think it's a bit more than that, at least in the audio area clean up 
-- not hard, but we need agreement from a few more people that are 
smarter than me. I don't want to go about changing the concept of the 
audio functionality (which is needed IMHO) w/o agreement from both the 
people who will use it, and from the general community on how it will 
fit into the overall design/usability of Squeak.

 From my experience, some audio classes are intertwined. For instance: 
something you probably already found, AbstractSound has instance methods 
that store audio files. Some of these methods use other audio class 
methods. As an example:  AbstractSound>>storeAIFFSamplesOn: uses the 
SoundPlayer samplingRate class variable -- and this class variable is 
hard coded at initialize -- not good for the SoundPlayer tool and worse, 
it makes storeAIFFSamplesOn: not reusable.
This isn't a hard problem to fix in code -- but it is in the overall 
design of the system: I think it boils down to what object should 
maintain attributes of the audio capture -- a design issue.  I think 
it's obvious, but we just need agreement before we change the design. 
(ok, maybe it's not a great example cause it's easy. But, I've had to 
override audio classes so that I could make them usable -- I didn't want 
to fork off and not be compatible with future versions.)

Other things are easier to tidy up. For instance, the same method uses 
an instance method named AbstractSound>>isStereo --- but it is hard 
coded to return 'false'. yuck.

So, for me, I think we need to look at all the audio classes, uncover 
the problems, and come up with a design (and I'm not saying a complete 
redesign) and a plan to execute.

>  
>
> Just as an example what about these?
>
> aURI playVideo
>
> aURI playAudio
>
> aURI play        "uses a specific player based on the file type"
>
> aURI edit        "opens a specific editor based on the file type"
>
> aURI editAudio          "opens an audio editor on just the audio 
> stream of the file"
>
>  
>
> When we figure out where we want to get to, we can work out how to get 
> there.
>
>  
>
> As for the question below, yes I am interested in re-useability, 
> something that everyone raves about for OO and Smalltalk but something 
> that Squeak is very bad at doing in practice.
>
> I am not a "programmer" although I program ;) so I will write code for 
> the framework. I already have a simple MM framework but I need some 
> help with the design, I am not experienced enough to know which are 
> the better OO ways of doing things.
>
>  
>
> Russell
>
Can you explain more about what you mean by framework? What are you 
proposing and at what level?
Is this an analysis of the current design? Or is this from a user 
perspective as you described above (aURI playAudio)

If you take my example above that focuses on audio only, and blow it up 
to add other MM types, it becomes a bigger and more complicated design 
issue. Thus, my initial cry to the Squeak community. It's not 
rocket-surgery, but it's bigger than me.

brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050225/ec6d5e7f/attachment.htm


More information about the Squeak-dev mailing list