[sugar] TamTam roundup.
Fri May 18 13:46:24 EDT 2007
*Apologies for dups
TamTam team has been on the sideline the last few weeks to let the
academic year conclude. We are warming up the engine at half-crew
until June13th and full tilt after that. We have proposals and many
questions. Our task list until September/October will be like this:
1- Solidify TamTam on the new B4/B5s.
- We have enough CPU/RAM and file space to do what we need to do.
Chunking out the audio data seems reliable but we would like to have
better keyboard response. Onkey presses feel laggy. This is largely
due to our buffering. We currently use 128 blocks of buffering. 64 is
desired, but it causes crackles due to CPU choking. This may not be
true on the new machines. Be that as it may, I think it will always
be difficult to run TamTam and another app at the same time. Is this
really a big problem?
- We are considering a move to a 22k sampling rate. This would
improve audio quality famously, specially where headphones, pods and
external speakers are used. This will be done with the sound bank
revision, CPU performance allowing.
- Resinstating microphone recording in mini and Edit and keyboard
recording in Edit. We hope this will be straightforward.
- Solve all popup window issues (yes, some remain)
- We can do almost everything on the machines we already have but a
B4/B5 will be essential to test the hardware performance.
2- TamTam Jam and miniTamTam
It is still uncertain if TamTam Jam will be a separate sub-activity.
We are thinking of making it an integral part of miniTamTam, which
would be renamed. The suite would thus revert to a three-prong
affair: Play, Compose, Make sounds. The miniTamTam performance music
loops we have been investigating are what motivated this rethinking
(see below). Performance scenarios with sync locked loops will be the
essence of TamTam Jam, along with screen feedback acting as a "tutor"
for composed music.
We think TamTam Jam will be the most used TamTam app. Four of us put
together a little performance at the Elektra festival
(elektrafestival.ca) last week. It turns out the little machine makes
a terrific orchestra instrument. We had beats going, sequences on
individual keyboard keys, imported sounds from synthLab. We played
only in miniTamTam. The four machines were connected to a minimal PA
(something that can be found in the most unlikely places in the
world). We did a little improv and the concept of playing XOs as a
band became immediately clear: people can make music together in
groups. For rehearsal purposes, with four or five people sitting
around a table, the small speakers are fine. We could use a little
more volume of course, but in a quiet environment, they are quite
* A hardware idea. Someone should think of the following device: a
tiny line mixer with 8 inputs and 2 outputs . Power requirements to
include a modest line amplifier are minimal. This device could be
used for group music making, teleconferencing activities and whenever
you need to connect a number of machine audio together. Small plastic
box, perhaps two or three per schools with a variety of adapters to
connect to any loudsepaker. I wouldn't be surprised if you could
make these things for less than 50 cents.
One thing needs solving: a clock pulse over the mesh so the beats
stay tight. As it is, you can start any number of machines on the
default tempo, and the machines will stay in sync for as long as two
or three minutes. This is musically useful but re-synching manually
kills the "?lan". So we need this clock. We have figured out how to
do it in our code and will, in all likelyhood use the presence
service. Right now however, the mesh remains slightly mysterious as
to its usability. We can shortcut with a pipe to Csound itself and
let it handle sync broadcast and reception outside the sugar
environment but that seems the wrong way to go.
A central question remains: Will a lightly loaded mesh (say, 10-12
machines) show enough latency to be musically objectionable? In
pratice, sync packets have to reach clients within 10ms, with a
prefferred figure of less than 5ms. By the time the signal makes it
up and down the software chain, it gives us something in the order of
50ms to make the graphics do what they need to do at that moment.
This is acceptable as a drop-dead timeframe. Outside this window, the
music is just going to gradually "loose the groove". Can the mesh
support this rate continuously? If so, we have a mightily rich
collaborative music setup.
For one flavour of TamTam Jam, google "Dance Dance Revolution".
3- Sugar conformity and integration.
We will need to travel to Boston for that and hopefully enroll Eben
as a "scream-across-the-hall" consultant. As much time we spent on
the look and feel of TamTam, we understand, accept and even look
forward to making it fit into the Sugar graphical idiom. The Sugar
controler toolkit is almost complete enough for our purpose. One
thing we will miss is a bidirectional slider but this is fairly easy.
Kids want to know: Do we get editorial control over the final
4- TamTam tunes outside TamTam
We want to propose a simple embeddeable TamTam player so kids can put
their compositions into documents. The player itself is simple enough
to make. AbiWord would be the first target. Any comments by the Abi
people would be welcome. This is perhaps a problem for OOM. Csound
needs to be loaded and Csound pre-loads sound tables into RAM and the
full library at 22k will pop a good 10 Mb. Is this realistic?
5- Tutorials and field trials
TamTam Edit and synthLab are complex applications for a 10 year old.
We look at those as something a kid can grow into and there is lots
to learn there. We will develop text-free tutorials to show the kids
how to use the apps. To that end: is there a flash player in the
works that can be used at small overhead?
We are planning some with-kids analysis sessions in late June to see
what works and what does not. We also need feedback from kids abroad
and developers who may have something to say about it. Are we
expecting detailed reports from the field trials in Brasil and Nigeria?
The sound bank will be fully overhauled, hopefully at 22k sr. On the
sounds themselves, what shoudl be the policy for a standard sound
bank and what will be the mechanism for exchange of sounds over the
mesh? Straight audiofile transfers via the Sugar shared spaces?
These are intial thoughts and questions.
On 16-May-07, at 8:02 PM, John (J5) Palmieri wrote:
> Here is a patch that will make tamtam work with our latest developer
> builds. There are still some issues I see with rendering TamTam
> but now they at least show up :).
> For speed, I have taken the liberty of fixing this in the current
> release and naming it TamTam-28.xo. Please bump the version to 29 in
> the next official release.
> (CCing Olivier because he was the last to commit to the git repo)
> John (J5) Palmieri <johnp at redhat.com>
> Sugar mailing list
> Sugar at laptop.org
More information about the Sugar-devel