From: John C. <j4s...@bi...> - 2004-06-01 23:35:44
|
On Tuesday 01 June 2004 04:07 am, Werner Schweer wrote: > On Tuesday 01 June 2004 01:31, John Check wrote: > > On Monday 31 May 2004 12:13 pm, Werner Schweer wrote: > > > On Monday 31 May 2004 17:51, Mathias Lundgren wrote: > > > > BTW, Werner.... > > > > > > > > > > > > We noticed that the controller pane doesn't include the old editor > > > > where one could add custom controllers. I guess this has to do with > > > > the new way of handling controllers, sysexes etc... > > > > > > yes, controller handling has changed a lot. The list of available > > > controllers now depends on the selected instrument (GM/GS/XG etc) and > > > is defined in the *idf file. For software synthesizer there is an > > > interface provision to tell MusE about all supported controller. > > > > > > > I'm wondering if changes on this front have calmed done in a state > > > > that it's possible to restore/recreate that editor again, since it's > > > > a very neat, not to say crucial, feature. Or are you planning any > > > > other controller-related changes? > > > > > > i want to unify controller handling for audio and midi. The keyword > > > here is "mixer automation". Midi controller should be treatet as > > > automation events and only played in automation mode "read". > > > This is currently not implemented correctly so some changes will occour > > > in this area. > > > > Shaking my head. There's so much wrong with that scenario. Can you please > > elaborate? > > For midi we have already complete "mixer automation" in that we can > record and play back all kind of controllers. The implementation is not > complete when it comes to the midi mixer (as part of the midi/audio mixer). > > For midi we deal with three kind of controllers: > - controllers recorded along with normal notes as part of the > performance (sustain, pitch, or think of a midi sax where you > can "play" some controllers) > - controllers which are changing over time and are entered graphically > (expression, pan etc.) STOP! This is _one_ kind of controller _not_ _two_. A pitch wheel, mod, aftertouch are all changing over time! Why are you splitting it up?!?!? > - controllers which are set to an initial fixed value at the beginning > of the song (example: program change). The list editor is preferably > used to enter such initial setups. As per the MIDI file spec. > > The graphical controller editor and the list editor is normally all what > you need for "automation". > Well, it depends what you mean exactly. A list editor is a must, but a graphical editor.... If the faders snap-to, and you have a read/write/update status indicator, what more do you need graphically? Have you ever spent time with a real automated console? If you don't have flying faders you have a tri-color led and the fader doesn't engage until it's lined up. BTW can we get a visual metronome? Just a flashing box will do it. > Things are getting somewhat confusing when you use the midi mixer. > Its not obvious what should happen when you drag a slider or turn a knob. To whom? The slider should control the synth MIDI volume, the reverb/chorus/pan should be pointed at the synthesizer as well. Synths are totally self contained as far as fx and a mix buss goes. You should get out what's basically a stereo submix. If it's a multitimbral synth, you should also be able to get dry mono or stereo. Make the MIDI mixer channels all mono, but lockable in pairs. When locked, they hard pan. That's the way it works. I just reread that paragraph and..I'm thinking about the way you gave special treatment to the softsynth MIDI path.. You should ditch that. A synth is a synth is a synth and it doesn't matter. > First the corresponding controller changes are send to the midi device. > This is expected and you can hear it immediatly. But when you start > the transport the controller value will jump back to the last recorded > value. This is something you may not expect. When you drag a slider Uh.... Why not? > while play the slider jumps back at the next recorded controller event. > Actually in read mode it should stay locked so nobody bumps a fader (time is money). I'm gonna be strapping a fader pack on at some point so. In write mode it should overwrite, and update mode should work like your saying. All you gotta do is hit update and/or write before you roll transport. > For every controller in the mixer you have to decide what should be done > when changing value: > > - read mode > the controller is "automated", values are from the recorded track; > if changed the controller can jump back unexpectedly > - write mode How is it unexpected unless you're picking up somebody else's project? Think about it, you have to have set the values in the first place. > the recorded values are overwritten while _play_ with current > slider/knob values > - touch mode > the controller is in "read" mode. If you click the controller > it switches to "write" while you drag the slider. When you release > the slider, the controller switches back to "read". > Where did you get "touch mode" from? It's _almost_ there. When you engage it, it should update the fader position to the stored value for continuity.. > The automation mode can be changed on a track base. It should be possible > to select the automation mode for a single controller (which is not > implemented yet). Of course only controller which are visible in the mixer > have an automation AUUGGGGHHH!!! You are _so_ over engineering this thing. The only problem with using MIDI for all your automation needs is _resolution_ > mode. All other controllers are implicit in "read mode". > Controller automation modes for midi are not implemented yet. > You have pitch bend and shit. Theres nothing special about the other controllers but the index number. > To summarize some changes between MusE version 0.6 and 0.7: > > - midi mixer and audio mixer are unified; the goal is to minimize > the number of concepts with midi- and audio handling > A worthy concept. > - MusE keeps track of midi controller events; The concept of > events is an implementation detail. The user should see controllers > as changing values over time. After a seek midi controller events As opposed to over dinner? > are send to the midi device to set all controllers to the right value for > the time position. Yes, you seem to have grasped that. I do get a sense though, and no offense meant, that some of you guys would be a little hazy if I threw you in a room with gear and cables. It doesn't make you a bad person, but if you're just used to doing this kind of stuff on the computer, there are things you wouldn't be aware of.. > > Regards, > Werner > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer |