Re: [linux-audio-dev] Sequencer Concept Addition

On Sat, Apr 30, 2005 at 05:32:59PM +0200, Tim Orford wrote:
>
> looks nice.

Thanks.
 
> i think its quite conventional though, albeit with the
> addition of per-container tempo/timesig.

Neither being conventional nor being unconventional
has been a goal by itself for me ... ;-)

> you dont say much about global horizontal or vertical
> settings. By 'global vertical', i mean Tracks. Its
> important, i think, to be able to set properties on a
> collective or default basis, as well as overriding or
> modifying them individually.

The absolute time / transport containers can be used for
global settings. If you want settings for a sub group to
persist through the whole arrangement (global vertical),
you would just create a container that extends from start
to end, just like a track. So you can, but are not forced
to use a from start to end entity.

> Similarly, i see the need for 'global horizontal' settings,
> for example allowing tempo changes across all child
> containers. Its not clear whether your model would allow
> that.

Everything inside a container with meter/tempo will
follow each tempo change of that container
(inside -> in sync with parent).

> I dont think tracks neccesarily add space. Especially if you
> optionally allow, for example, a per-container output
> channel, as has been in Cubase since v1.0 (well actually
> thats per-note, but the concept is similar).

I was thinking about things like mostly empty tracks, with
just some clips or midi now and then (FX, crashes ...).
It happened to me that i felt reluctant to add such extras
as I didn't feel like setting up another track just to have
independent effects and volume.

If you allow per object or region settings you are already
close to my container concept. But it makes sure all that
is visualized.

 
> I agree with you that a general purpose library or deamon is
> sorely needed to encourage a rich interface ecosystem.
> Theres no good reason why a user shouldnt be able to use a
> Radium style interface while simultaneously using a
> conventional graphical window displaying the same data.

Thanks for your thoughts, Tim

---
Thorsten Wilms