RE: RE: JamMan modifications

["Sellon, Bob" <bsellon@lexicon.com>]

Kim wrote:
>I didn't totally follow the "page" thing. How is that again?
>What do you mean by "simultaneous loops"? Do you mean four independent
>tracks playing at once as a loop? I didn't think the Jamdude had the
>processing muscle to do anything like that. Or do you mean four discrete
>loops which are available to switch between?

I'm actually talking about 4 independent tracks playing at once. It was   
something that I really wanted to get into the original Jamman but we   
couldn't figure out how to deal with it in the user interface. The answer  
 
was the concept of a "page". In the new software I'm working on, I refer   
to the combination of all loops currently playing as a page. Each page   
can contain up to 4 loops/delays/samples (channels?), each with a   
separate level and pan control. You tap in the first loop in a page then   
select other channels which, currently, are initialized to the same size   
as the first loop. We currently allow a particular channel to be divided   
down when in the echo mode but I will probably fold that into the loop   
mode as well. When you need a clean slate, you switch to a new page. The   
new page gives you up to four new loops/delays/samples. We are currently   
have up to 4 pages. Each page stores the pan and level of each   
loop/channel. Pages are changed on the loop boundries which is where I am  
 
running into problems with the odd loop sizes. The hardware is capable of  
 
having all four loops be any size whatsoever but I still have to work   
through some of the issues of changing pages, etc..

With regard to the processing muscle of the Jamman, there is actually   
some to spare even with the features I have mentioned. The original   
Jamman only used a microscopic portion of the audio processing power of   
the DSP in the box. There are limitations to what I can do with the   
remaining processing power but the prospects are pretty exciting. The DSP  
 
at work here is the same processor that generates all those lovely   
reverbs that Lexicon is known for. I'm trying to do as much as I can with  
 
the hardware but I'm deeply concerned about the user interface.

>The issue of rhythmic freedom vs. various degrees of synchronization is   
a
>fundamental problem with multiple loops, I think. The effort involved in
>making these features musically useful on the echoplex was huge, but   
worth
>it. Basically, you have to give the musician the option to choose. And   
the
>musician should be able to make the decision on the fly, with a minimal
>amount of setup. Some musicians (like Matthias) do not want any
>synchronization, insisting that they always be free to tap the lengths
>wherever they please. And some, (like me sometimes) want precise
>synchronization, allowing for polyrhythmic relationships. And most   
times,
>different types of music and different situations just call for one or   
the
>other. Tough challenge for the designer!

Definitely. As I said, I'm very concerned about the user interface for   
this kind of stuff. I really don't want to spend a lot of time on   
features that are so weird or to hard to use, that no one uses them.

Ed said:
>Bob, is there a way to offer both functions to the JamMan upgrade   
depending
>on which "mode" you wanted? Obviously if you are in the "synced" mode   
you
>would want all loops to be the same length.

Kim wrote:
>Actually, no. Sometimes you want them to be multiples of each other. Say
>loop 1 is a four bar verse section. For loop 2, you want a 16 bar chorus
>loop. So it has to be exactly 4 times the length of loop 1. That's a   
pretty
>common need.

Actually, yes. As I said earlier, in Jamman the loops can be any sized.   
It's managing them that is the problem. My current thinking is to let   
each loop (in a "page" of up to 4) play out then switch to the loop   
assigned to that channel in the next page. Given this senerio, would you   
like the alignment of the loops in the new page to be initially sync'd in  
 
any way or just start at the loop boundry of the previous loop/channel?

Ed wrote:
> One thing I've found
>frustrating if not impossible to do with the JamMan is if I'm playing a
>rhythmic loop with the JamMan but I'm not synced up to anything (drum
>machine, sequencer), say I'm just playing guitar and I want to switch to  
> 
a
>second loop it is very hard if not impossible get the second loop to be
>exactly timed right. My timing is pretty good but but it still takes
>several passes, if I'm lucky, to get the second loop to line up. This
>limits trying to use this live.

Kim wrote:
>You need a good time copying function. It should let you record the   
second
>loop while the time is being set up, so that there is no interruption in
>the performance. The second loop should somehow stop recording and begin
>looping automatically when it reaches a multiple of the first loop. The
>echoplex does this by combining the NextLoop and Insert functions, which
>worked out miraculously well.

Ed, I not exactly clear on why you are having so much trouble   
syncronizing  the second loop. If you are using multiple loops, you   
should always "Tap" on the first beat of the loop. This is vitally   
important because this is the point at which changes from one loop to   
another take place. If you tap on 3, Jamman will start initializing the   
second loop on the third beat of your current loop which gets confusing   
real quick. When you tap in the first loop try to tap exactly on the   
first beat. All of the loops are the same size on the current Jamman so   
the second loop will automatically be the same size as the first.   
Remember, however, that you DON'T need to tap in the second loop. Simply   
use the loop (? Channel?) button to select the next loop and let Jamman   
handle the rest. The "time copy" function is built in and automatic.

Ed wrote:
>If the loops didn't have to be exactly the
>same length though, you could switch loops and even if the second loop   
was
>slightly shorter or longer than the first it wouldn't matter as each   
loop
>would maintain its own "integrity".
>There are times when I do want to sync so it would be nice to have   
either
>mode available. Maybe there is a way to implement both depending on   
which
>mode you want to access, synced or non-synced. What do you think?

I think it can be done, I just need to work through a few senerios. I am   
working on it, however, so I'll keep you posted. Thanks for the input.   
It's definitely appreciated.

Bob Sellon
Lexicon/Stec