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
|