Looper's Delight Archive Top (Search)
Date Index
Thread Index
Author Index
Looper's Delight Home
Mailing List Info

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

Re: MIDI looping



Sorry if this is getting too geeky for any of you...

>Most important con:
>        There is no easy way to simulate feedback and let the notes fade
>and leave them behind at a certain point. But it should be possible.
>But a lot of kinds of loop music do not need the feedback feature.

Well, the way I did this before, which I assume is reasonable, is
to treat note-on velocity as "volume", and decay that as your feedback.
You have to be using patches that do translate volume this way, plus
you get the ability to have notes do other things (like have filters
clamp down) as the notes fade out.

You can drop a note out when it's gotten to a certain velocity, or
you can drop them after a certain number of generations.

>>  con: no effects in the feedback path
>>   but: most people don't use their loopers that way anyway
>
>Right: The available dedicated Looping devices dont let you insert in the
>feedback path either. The delays like PCM42 and t.c.2290 have it, because
>they do the feedback all analog, which is not very sutable for looping in
>other ways.

Well, I've started specing a design for a performance-oriented
MIDI looper, and one thing I've discovered is that there is an
_enormous_ number of special effects you can do by processing
the notes during feedback.  Now, it is _totally questionable_
how useful these effects are; much like getting a guitar multi-FX
box and playing the pre-programmed patches, and finding them useless,
if you got a MIDI looper and just wanted it to loop, then you're not
necessarilly going to want these sorts of things--rather, they
would motivate certain compositions, and thus might only be useful
for one planned-out piece:

- every loop, transpose up a fourth (or any interval)--of course,
  any non-looped music needs to follow along, or it becomes dissonant

- apply a "smart harmony" (which stays in a single key) to transpose up
  some interval, so now the non-looped music doesn't need to slave to it

- use slightly different delay length for every pitch, so a chord
  spreads out over time each delay

- rather than having a volume reduction in feedback, make the delay
  time get longer and longer _per note_, so maybe each note echoes
  after 4s, 8s, 16s, 32s...  Thus, the texture will get sparser, but
  not by fading out, but by notes playing less often

I've also written down some more bizarre effects like having different
notes in a chord pitch shift in different directions, and having notes
detune (pitch shift by fractional amounts) as they echo, that are of
very questionable utility.

>>  con: another MIDI delay in your signal path
>>   but: you can use your performance synth (e.g. guitar synth or 
>keyboard)
>>       to provide the initial tone, and then the extra MIDI delay can
>>       be compensated for by reducing the first iteration's delay time
>>   but but: now you need another sounds source with very similar sounds
>>       to your initial sounds
>
>hm... there is no way you can merge the the two contol signals?

Well, in fact, if you're playing on a keyboard with a MIDI in and a
MIDI out, and it's well behaved, then you can in fact route the
output of the MIDI loop back to that keyboard.  I don't know how
many are well-behaved.  And I don't know how many guitar synths
have a MIDI-in.

If you imagine you're playing through a guitar->MIDI converter,
like the GI-10, then you'd need a pretty messy setup to try to
avoid the extra MIDI delay from the looper:

 naive:  guitar->MIDI --> looper --> synth

 direct:                 _--------------_
         guitar->MIDI --<_              _>-->synth
                          --- looper ---
                                         |
The problem is that the merge operation (|) requires an
extra little MIDI box, which probably incurs extra MIDI
delay as well, so this setup probably wouldn't speed up
the direct notes, except if the looper doesn't get direct
notes back to the output very fast.

>>  con: probably harder to create the software for
>No, I do not think so.

The main thing that I'm worried about is that MIDI is channel-oriented.
So if you play a note and bend it, you get pitch bend data on that
channel.  To output it, you need to play that note on its own channel,
so that the pitch bend doesn't bend other notes accidentally.

If you play _every_ note on its own channel, then you only get
16 notes at once, and for a big thick looped texture, that's not
enough.  So I'm imagining that you'll want really smart software
that allocates notes to their own channels if they need it (because
they get pitch bent or have some other MIDI continuous controller
applied to them), and otherwise puts them on one channel to conserve
channels.

Which seems like a mess.  (There are two better solutions: have
several MIDI outs, so you have more than 16 channels effectively
(but now you need several synths, so we're no longer low-budget);
or, use ZIPI instead of MIDI--but now we're in fantasy land.)

Also, audio data is really simple.  You get the sample,
you multiply to change its volume, you add to mix.  You're just
keeping one big queue of data in your delay, etc.  MIDI data is
made up of variable-sized packets, there's running status, etc.
etc.

Still, never having written either, I'm happy to defer to your
judgement on the complexity issue.  And not like it matters to
me--whether it's harder or not, it's not "too hard".

>and pro: You can create programs that for example repeat each input 
>exactly
>4 times (at same volume) or more complex patterns like repeat twice / wait
>6 / play twice, softer...

Unfortunately, finding a user interface for such things is
going to be an enormous mess.  But it's definitely well suited
to all sorts of bizarre stuff that's just not feasible in audio,
because it never actually mixes the notes together the way an
audio looper does, so it can do all sorts of per-note stuff.

>Consider also to make it compatible with the existing looping devices to
>simplify operation and synchronization.

Totally.  Clearly it's hard for an audio looper to sync, since if
it doesn't want to pop if it gets out of sync, it needs to actually
change its sample rate, or maybe cross-fade the beginning and end
of the loop.  A MIDI looper can just play all the remaining notes
and jump to the start of the loop.  So making it slave seems smart.

>I could even imagine a unit that looks about like the Plex, but cost a lot
>less for doing the same only in MIDI.

I figure you could do a fine MIDI looper with a little box with
a 68020, 128K of ram, MIDI in and MIDI out, and some amount of
non-volatile memory for patches.  (Actually, for all I know,
a true 68000 would be fine.)

However, I'm not aware of anything like this available as a kit
or pre-made.  On the other hand, I can get an old Atari ST for
$50, which gives me 512K of ram and a floppy drive.  So my current
plan (but no promises) is to try to make an ST MIDI looper, at
least as a prototype.  The advantage of the ST over a PC or MAC
is that I can use it in performance more easily (since it's a
single piece), and it's cheap enough I can get another as a backup.

(Ok, really, the ideal box has at least 2 MIDI ins and 4 MIDI outs,
so the ST is less than ideal in that dimension, whereas plenty of
MAC or PC interfaces would do better.)

Sean Barrett