Re: Import a MIDI file

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Tue, Jul 03, 2007 at 11:17:41AM +0200, Tim Janik wrote:
> On Mon, 2 Jul 2007, Stefan Westerfeld wrote:
> >On Sun, Jul 01, 2007 at 03:25:20AM +0200, Tim Janik wrote:
> >>On Tue, 29 May 2007, Stefan Westerfeld wrote:
> >>>On Tue, May 29, 2007 at 12:54:52AM +0200, Tim Janik wrote:
> >>>>On Mon, 28 May 2007, W.Boeke wrote:
> >>>>>I imported a MIDI file and got all the channels listed correctly
> >>>>>in the beast window. I then mapped each channel to an existing
> >>>>>synthesizer, however then the show stopped. What can I do further?
> >>>>
> >>>>hm, testing it out it seems you still need to assign the tracks
> >>>>to at least the Master mixer bus for playback.
> >>>>
> >>>>beast also has a script that is meant to be usable for this, however
> >>>>it currently doesn't work for me.
> >>>>Stefan, does Tools/Song/Assign-Tracks-... work for you? it doesn't
> >>>>seem to work after a MIDI file import or a new project with a single
> >>>>unconnected track here. can you reproduce that or do you need a bug
> >>>>report about it?
> >>
> >>>It works the way I designed it, that is, it only reassigns those tracks
> >>>that are connected to master, and no other bus. It does this because:
> >>
> >>>So: just the midi import needs to be fixed, the script does the right
> >>>thing.
> >>
> >>i don't agree with that statement. granted, the midi import needs to be
> >>fixed, but there are other ways to end up with an unconnected track.
> >>in such a case, the script name is simply misleading when it says
> >>"assign tracks to individual mixer busses". it should either be renamed
> >>(according to your description, to: "assign _connected_ tracks to
> >>individual mixer busses", but that triggers the question of where an
> >>*unconnected* script variant is) or be fixed to reconnected
> >>disconnected tracks as well. i'd say the latter is the obvious choice
> >>and fail to see a good reason for the script to not connect currently
> >>unconnected tracks.
> >
> >I often use modulation-only tracks (assigned to the same midi channel),
> >like
> >
> >Track-01   Master    [ Part1 ] [ Part 1 ] [ Part1 ] [ Part 1 ]
> >Track-02     -       [  Filtersweep Up  ] [ Filtersweep down ]
> >
> >This allows me to sequence notes and controls individually, i.e. repeat
> >the same notes over and over again, while changing the frequency of the
> >filter within the instrument. Of course, I don't want that these
> >modulation only tracks "waste" a mixer channel, so I made the script
> >only reassign those tracks that are assigned to master.
> >
> >You can see the effect in "Party Monster" - the synth bass modulation
> >track (which is such a modulation only track) gets ignored by the script
> >if you run it.
> >
> >
> >So as far as I can see there is a use case for the behaviour I
> >implemented, unless we find a way to express seperate modulation in
> >beast with the same elegance but in a different way than I do it right
> >now.
> 
> fine, what about adding a checkbox to the script then that preserves
> your use case behavior?
>   [ ] Only assign tracks connected to 'Master' bus
> 
> >But I've personally never encountered a use case for reassigning
> >unconnected busses other than the midi importer,
> 
> yes, i know. that's why i keep telling you that *others* are 
> encountering these cases. so the use case exists, even if it 
> isn't exhibited by your personal usage patterns.

It would be great if you could share your insight into the goals,
motivations, workflow and usage patterns of these other users to a
degree that I can clearly understand that you are right.

I deliberately used the term "use case",

  http://en.wikipedia.org/wiki/Use_case

because I didn't only want to know that you want me to change the
script, but because I wanted to know precisely why anybody - not just
theoretically - but a real user in the real world - would benefit from
that change. I described my use case at the same level of detail above.

So saying: somebody needs it, trust me, is not enough.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan