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
