My thoughts

[pljones]

Some ideas...

-----------

My basic thoughts are to extend the MIDI model in Muzys into the audio domain. I'm not specifying what the UI shoud look like... Basically, any audio created (either from a sequenced sample or from a plugin) gets routed by the event that caused it primarily, unless it "hands off" the audio. Muzys did this for MIDI by having "Track's Player" override "Part's Player" and that override "Event's Player". (Excuse the "\-", it's sort of a TAB...)

midi event can route to:
part's midi sequence
or event's player - resulting audio can route to:
\-part's mixer
\-or assigned mixer channel

audio sample can route to:
part's audio sequence or mixer channel
or assigned mixer channel


part's midi sequence can route to:
track's midi sequence
or part's player - resulting audio can route to:
\-track's mixer
\-or assigned mixer channel

part's audio sequence can route to:
track's audio sequence or mixer channel
or assigned mixer channel


track's midi sequence routes to:
track's player - resulting audio routes to:
\-assigned mixer channel

track's audio sequence can route to:
assigned mixer channel

-----------

I should be allowed to load one player per event, if I've got enough RAM (if they're all the same VSTi, then it's all the same DLL, only the instance-specific data changes...).

-----------

Where do these "MIDI events" come from? Sequences and MIDI In ports. These should be treated the same -- a Part (etc) might have its event source assigned to a MIDI In port . MFX plugins need to fit between the event source and the rest of the host, I suppose...

-----------

ReWire clients... I guess that just sits there on a "return" feed into a mixer channel driven by MIDI time code (Mbt). I think it should, therefore, appear as a mixer channel "coming from" a particular ReWire client.

ReWire servers... Will MUTON act as a client? I guess that just means letting the server drive Mbt and using the ReWire audio outs rather than soundcard outs as final destinations for mixing. (But why spend time making it a client? Mmm... the only reason I can offer is "feature count" )

-----------

These Mixer channels... I want to be able to change the "final" destination to another channel (rather than having to Mute the channel) if I need more slots. Or don't have a fixed number of slots, of course. That would be better...

I can already create new mixer channels and route amongst them nicely, so I can't really think of much else I need from the mixer... Apart from unlimited everything .

[muzycian]

Some ideas...

My basic thoughts are to extend the MIDI model in Muzys into the audio domain.
...
midi event can route to:
part's midi sequence
or event's player - resulting audio can route to:
\-part's mixer
\-or assigned mixer channel
...
track's audio sequence can route to:
assigned mixer channel

I think i see your picture:

It's about a hierarchic relationship between tracks-parts-events for both Audio and MIDI, right?

I should be allowed to load one player per event, if I've got enough RAM (if they're all the same VSTi, then it's all the same DLL, only the instance-specific data changes...).

This is already the case, right?

These Mixer channels... I want to be able to change the "final" destination to another channel (rather than having to Mute the channel) if I need more slots. Or don't have a fixed number of slots, of course. That would be better...

And how would you bring this gui-wise?
A little scrollbar in the mixer to scroll thru your plug-slots?

Anyway,
It's interesting and nice
to think modular-wise

[pljones]

I've had some more revelations

Once you've got a "sequence object" (either a MIDI port or a stored sequence), you need to be able to apply a filter (MFX or internal) to it and have the output treated as another "sequence object". That lets me route MIDI channels to different players, parts, etc... Or use a filter to transpose or quantise or remap, etc. You get the idea... And then, of course, as that's a "sequence object", you can apply another filter... etc...

Yes - the aim is to keep it structured/hierarchic and modular without being overwhelming. So it's trivial to say "this is the drum track" and assign it to a drum synth. Everything on that track then gets routed accordingly - MIDI triggering the synth and all audio to a specific vocal drum processing set up ("mixer"). Or "this is the vocal track" - all sampled vocals going to the vocal mixer. This is the point with the audio and MIDI convergence: any audio created by a MIDI sequence on this track would also go through the same process.

It doesn't need to be easy (or even possible, I suppose) to let a single Part opt out of the Track configuration unless the Track says "Use Part Settings". And I'd be inclined not to let Parts overlap... (so no built in limits on numbers of tracks... on the full version...)

GUI-wise... Let's see: you ask for the plugins contained in the "component" you're dealing with and get a directed network of connected plugins back. By using the word "scrollbar", I'm guessing you're not planning something like EnergyXT's interface (or SynthEdit)! Mmm... hmm... ("But it is a directed network...") How simple does the interface want to be? You seem to have moved to allow plugins to be used as instruments if they take MIDI in and as effect anyway. But are you going to support effects with multiple audio ins or outs (i.e. more than stereo pairs)?

Oh yes, definitely I'm thinking modular-wise

=edit - 17 Jan 2006, after next post...=
Oh, I can't stop myself...

All controls in MUTON need to be modulation targets (tempo, sequencer start, punchin location, selected MIDI source... as well as the more usual ones).

Then everything which has a value should be able to be used as a modulation source, too...

As well as the obvious MIDI to modulation control, there should be audio to modulation control conversion... Both should have lots of tweakable parameters...
=/edit=

One thing I liked about SynthEdit -- don't know if eXT has it -- you could select a bunch of related components and turn them into a single component, thus "hiding" their complexity... Mmmm... ("Patch"-making fun...)

[pljones]

I better stop thinking about this: I want to turn MUTON into a modular workstation... So I'll throw in my other idea, instead .

Make the studio / session file format plain text, with similar rules to the sfz format that René uses. That way you can trivially add or drop stuff from the session file without too much worry about versions of the format. Indeed, uses should be able to swap files fairly easily without worrying, too, so long as "unrecognised junk" and order are preserved on write... (There, I hit a "fun" button again!)

[muzycian]

Yo pljones,

About the modular design: Yes, i definitely see the picture.

In fact, i did design such pure modular internal system, and MUTON is using its partial implementation.

But because i encountered some technical difficulties AND because i don't have unlimited time right now, i have to make some practical compromises for now.

The main goal NOW - as step 1 in the MUTOOLS story - is a basic and effective sequencer-host.

Soon (within a month or so) you'll understand why i need to concentrate on the practical side right now.

But again, regarding the future, MUTON's internals are brand new and very modular.

And lateron we can work things out further.

Thanks for your constant emphasis on modular design!

It's essential!

Cheers,

Jo

[muzycian]

Make the studio / session file format plain text, with similar rules to the sfz format that René uses. That way you can trivially add or drop stuff from the session file without too much worry about versions of the format. Indeed, uses should be able to swap files fairly easily without worrying, too, so long as "unrecognised junk" and order are preserved on write... (There, I hit a "fun" button again!)

I've been thinking about this.

Now before i go deeper into this technically, i just wonder what exactly the advantage is?

Why store a session as an editable text/XML file?

That way you can trivially add or drop stuff from the session file without too much worry about versions of the format.

But you can add-edit-remove data in the application itself, without worrying about file format versions. Right?

Technically:

-> How to store binary data (like audio data) in a text file. By writing the bytes in hex-format? Then the filesize doubles. And it becomes practically unreadable again! (imagine scrolling thru millions of hex-bytes to go to the next text-tag)

-> How to store pointers to dependent objects?
e.g. a composition contains parts, pointing to sequences. How to store that sequence reference in a way that is "edit-safe"? By using a sequence-index? Or by sequence-name? (must be unique per session then)

Object-pointers should be written in a way that is edit-safe, i.e. if a user starts messing around with the file, it should be easy and safe, and making sense.

What do you think?

[pljones]

But you can add-edit-remove data in the application itself, without worrying about file format versions. Right?

Exactly.

It's mainly meant to make life easier for the developer. Application users aren't expected to start messing around with the text file. (Indeed, if you read about Dimension, hardly anyone wants to touch the .sfz files, even though that's the most powerful way to get anything out of the application (IMO).) It's more so you don't have to think "Oh, this file was written by version 0.0.3.0.5, so it's got 13 bits of flags and a three bit count in the seventy fifth byte pair after the start of plugin data mark but now that's represented by ..." etc. You read a "<field><whitespace>=<value><whitespace>" sequence and use "value" as the value for "field". If the field is unknown, you ignore it. If the data type is wrong, you ignore it.

-> How to store binary data (like audio data) in a text file. By writing the bytes in hex-format? Then the filesize doubles. And it becomes practically unreadable again! (imagine scrolling thru millions of hex-bytes to go to the next text-tag)

SFZ takes the non-monolithic approach: audio data in audio data files, the description in a text file. I guess you could package it all into an archive (jar/rar/zip etc - a bit like Firefox XPI files) if you like (and some sfz format users wanted this). So, for "known binary data types" (Audio, MIDI, FXB, FXP, etc) the non-monolithic approach means no doubling of data. For simple data (int, float, etc), use the "ToString()" representation.

-> How to store pointers to dependent objects?

Serialising and deserialising objects and references is something I'm only just starting to deal with... and maybe it does present greater challenges... (I think there are OO patterns for that kind of thing.)

"Object pointers" are references to uniquely identifiable instances of particular objects. So long as any object so referred to has a key field, that key can be serialised and used when deserialising.

There will be an ordering of object instantiation (i.e. if A refers to B, B needs deserialising first, I suppose)...

All this stuff I'm not that hot on for OO...

[pljones]

But because i encountered some technical difficulties AND because i don't have unlimited time right now, i have to make some practical compromises for now.

That's okay. I'm incredibly short of time, too. I've spent next to no time playing with Alpha 2, sadly.