30 Apr
2005
30 Apr
'05
9:52 a.m.
Hi!
I have been thinking about how an advanced sequencer could
look and work over and over again and now finaly managed
to come up with one consistent concept that i would like
to present here now.
A mockup to illustrate the following explainations:
http://wrstud.uni-wuppertal.de/~ka0394/forum/sequencer_05.png
The basic idea is to have nested containers to be arranged
verticaly and horizontaly. All information is tied to or
contained in these containers.
As the horizontal axis stands for time, i needed to express
the nesting only verticaly (plus color), so that's what the
round corners and the empty bottoms of the containers are
for. Maybe it helps when you think on Lisp and paranthesis,
only vertcaly.
On the mockup the big white container defines absolute
time (min/sec) and the context for playback control (only
one play position inside thsi container (for each user)).
Several of them could exist in parallel, all with their
own playback control.
The next, yellow container defines the meter (the ruler)
4/4, followed by a tempo track set to 120 BPM.
The blue container is an audio container. These can
take others of their kind, audio inputs and outputs
and finaly audio clips. This one defines an "Out 1"
and its send level and conatins 3 clips.
Below it, the green container sets a 3/4 meter.
Because it is inside the 4/4 container, the quarter notes
match. If outside, it would have to have its own and
independent tempo track.
The last Container is for MIDI. It has IN and OUT as
attributes. Alternatively these could be expressed on tracks
like used for tempo, what would make them changeable inside
the container.
Every Container can be used as a pattern (instances).
They could have a dropdown menu to swutch between
different versions (/takes).
I have some more ideas and details, but i think this should be
enough for now! :)
I have only basic and seldomly applied coding skills, and
this doesn't look like a one man project anyway ...
So I hope for interested developers ... or that at least
this gives someone some inspiration. I would be happy to
further develop my concepts of course (allthough my diploma
in industrial design, same topic: sequencer takes priortiy
for the next 3 months).
---
Thorsten Wilms
30 Apr
30 Apr
12:04 p.m.
New subject: [linux-audio-dev] Sequencer Concept Addition
Dang, i should have dropped some words on the
reasons for the container concep :)
- Making it easy to switch instruments, effects,
routing, etc. without the need to add several
tracks (therby wasting vertical space and making
it harder to get the 'big picture'
- Allowing to include tempo and meter changes,
as well as routing in patterns for easy
repetition.
- Making it easy to build up complex polyrhythms.
- The absolute time containers with independent
transport control should allow to integrate
loop recording/playing (like sooperlooper or
freewheeling). But I hav't thought through this.
Also one such Conatiner could include transport
events to control another one (the sequencer
playing itself).
And some words about architecture:
The sequencer should be able to handle audio,
midi, osc and later on video. For this the core
should deal only with what is common to all
containers and rely on plugins for the varying
kinds of content.
The (headless) core should concentrate on allowing
to record, arrange, edit and output data.
Multiple Clients could communicate with one server,
allowing collaborative sequencing (some additional
mechanism would be required, of course).
---
Thorsten Wilms
1:34 p.m.
New subject: [linux-audio-dev] Sequencer Concept Addition
hi Thorsten
looks nice.
i think its quite conventional though, albeit with the
addition of per-container tempo/timesig.
while i wouldnt use the tempo/timesig much myself, i can
see its a useful addition.
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.
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.
- Making it easy to switch instruments, effects,
routing, etc. without the need to add several
tracks (therby wasting vertical space and making
it harder to get the 'big picture'
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).
The (headless) core should concentrate on allowing
to record, arrange, edit and output data.
Multiple Clients could communicate with one server,
allowing collaborative sequencing (some additional
mechanism would be required, of course).
This is more or less what i am working on. Still nothing
usable unfortunately. If i cant get it together soon,
i'll probably just make the code public as is anyway,
so that people can see it...
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.
regards
--
Tim Orford
2:15 p.m.
New subject: [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
3:32 p.m.
New subject: [linux-audio-dev] Sequencer Concept Addition
On Sat, Apr 30, 2005 at 06:15:25PM +0200, Thorsten Wilms wrote:
i agree this is an important consideration.
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.
so, just to be clear, each tempo/meter container could
contain a complete tempo/meter map, not just a single pair
of values?
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 ...). If you allow per object or region settings you are
already
close to my container concept. But it makes sure all that
is visualized.
yep, thats cool, but i personally still wouldnt be happy
without the "track control" area on the left. Even if you
consider it to just be a shortcut to managing properties of
the containers. Also probably some of the visual container
items would by neccesity disapear at smaller zooms anyway. I
think its worth remembering that versatile systems are often
not very successful, as even if people can be bothered to
learn them, the flexibiliy has a habit of getting in the way
of the simple case which is in 95% of cases all that is
needed. Hence for example the common usage of the inflexible
one to one channel to track relationship model. This is
a serious issue for me as i resent having to use inflexible
systems merely for interoperability with the majority of
people who quite rightly dont want to spend their whole life
learning how to get an extra 2% productivity out of their
sequencer:-)
I like the rounded corners. I wonder whether they would look
as good when the boxes are smaller and there are lots back
to back? I'm currently using rectangles, which has the
drawback that you cannot see when containers overlap. I was
going to try a single "cut off" corner, but perhaps will try the
rounded corners also.
cheers
--
Tim Orford
4:37 p.m.
New subject: [linux-audio-dev] Sequencer Concept Addition
On Sat, Apr 30, 2005 at 07:30:56PM +0200, Tim Orford wrote:
so, just to be clear, each tempo/meter container could
contain a complete tempo/meter map, not just a single pair
of values?
Only a meter container that is not inside another meter
container can have a tempo track, as else they couldn't
stay in sync. But a first level meter container must (and
automaticaly will) have a tempo track, because otherwise
the timing of everything inside would be undefined.
Now if that sounds complicated ... in the common case
there will be only one meter container set to 4/4 with
tempo set to a fixed value. And the app should present
a default empty arrangement / template on startup anyway,
where something like that would be included.
yep, thats cool, but i personally still wouldnt be
happy
without the "track control" area on the left. Even if you
consider it to just be a shortcut to managing properties of
the containers. Also probably some of the visual container
items would by neccesity disapear at smaller zooms anyway. I
think its worth remembering that versatile systems are often
not very successful, as even if people can be bothered to
learn them, the flexibiliy has a habit of getting in the way
of the simple case which is in 95% of cases all that is
needed. Hence for example the common usage of the inflexible
one to one channel to track relationship model. This is
a serious issue for me as i resent having to use inflexible
systems merely for interoperability with the majority of
people who quite rightly dont want to spend their whole life
learning how to get an extra 2% productivity out of their
sequencer:-)
There could be a setup like in Garageband, where you have a main
view, and a detail view below where the selection is shown. I
don't know if Garageband also does that, but if multiple objects
are selected, they should all be shown there (for easily comparing
patterns, for example).
And containers could be entered / maximized on double-click
maybe.
If you only look at the common case and what is mainstream,
there will be no progress. And I don't think sequencers are
that far developed that this should be accepted.
Of course it's important to keep the flexibility and advanced
features from getting in the way of common and simple tasks.
I think it is possible to succesfully do so inside my concept.
A user could ignore the whole multiple meter option and use
containers mainly like tracks and all would be fine. But if
somebody wants to explore 3/4 in sync with 5/8, which would
change to 7/9 later on, he could!
I like the rounded corners. I wonder whether they
would look
as good when the boxes are smaller and there are lots back
to back? I'm currently using rectangles, which has the
drawback that you cannot see when containers overlap. I was
going to try a single "cut off" corner, but perhaps will try the
rounded corners also.
With many small boxes / zoomed far out it will not work so
well, of course. But most containers will be rather big,
and having round corners will be of advantage. Too small
containers will have to be drawn with hard corners, I think.
---
Thorsten Wilms
5:37 p.m.
New subject: [linux-audio-dev] Sequencer Concept Addition
On Sat, Apr 30, 2005 at 08:36:16PM +0200, Thorsten Wilms wrote:
perhaps you might not want them in sync. And, eg, a tempo
setting of 50%, would be very handy, even for 4/4'ers like me.
so, just to be
clear, each tempo/meter container could
contain a complete tempo/meter map, not just a single pair
of values?
Only a meter container that is not inside another meter
container can have a tempo track, as else they couldn't
stay in sync. But a first level meter container must (and
automaticaly will) have a tempo track, because otherwise
the timing of everything inside would be undefined.
i dont think i explained myself properly. Can i for example
in your mockup, change from 4/4 to 3/4 at bar 3 *within*
the existing yellow container. I think that would be
neccesary and I'm sure thats what you had in mind.
There could be a setup like in Garageband, where you
have a main
view, and a detail view below where the selection is shown.
I'm not familiar with Garageband, but from the apple.com
screenshots this appears to be a watered down feature of
Logic, where you can have an arbitrary number of arbitrarily
positioned windows showing these "details" (linked edit
windows).
But yes, i mostly agree:-)
--
Tim Orford
6:15 p.m.
New subject: [linux-audio-dev] Sequencer Concept Addition
On Sat, Apr 30, 2005 at 09:35:50PM +0200, Tim Orford wrote:
perhaps you might not want them in sync. And, eg, a tempo
setting of 50%, would be very handy, even for 4/4'ers like me.
If you don't want them to be in sync, just don't put
one into the other (of course there could be an option
to break sync even with nested meter containers, but that
would be in conflict with the whole concept. The relation
parent-child and the visualization would loose meaning).
And of course there should be a global (or per absolute time /
transport control container, not sure) % tempo control.
i dont think i explained myself properly. Can i for
example
in your mockup, change from 4/4 to 3/4 at bar 3 *within*
the existing yellow container. I think that would be
neccesary and I'm sure thats what you had in mind.
To be honest: no, that was not my original idea. But it
could be made possible, and would be more practical.
Good point.
I'm not familiar with Garageband, but from the
apple.com
screenshots this appears to be a watered down feature of
Logic, where you can have an arbitrary number of arbitrarily
positioned windows showing these "details" (linked edit
windows).
Aha, good to know!
But yes, i mostly agree:-)
Good :)
---
Thorsten Wilms
7142
days inactive
7142
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
2 participants
participants (2)
-
Thorsten Wilms -
Tim Orford