Possible bug in the H9 Looper

[Bodde]

When using the LOOP function of playback mode the manual says that the recorded loop should enter stop mode when the recording is done. But instead of stopping the loop enters play mode just like in AUTOPLAY. So now there is no difference between LOOP and AUTOPLAY. I think it is a bug (?)

Also the manual says P: LOOP and AP:LOOP which can be misleading while the playback 'button' in the H9 control displays AUTOPLAY. Better for the manual would be AP:AUTOPLAY I think. (this is a minor thing though).

One more thing. Not sure if this is bug though: When using the right footswitch of the hardware while in PLAY mode it displays STOP right away and you can empty the loop by hitting that switch twice after STOP Is displayed. But when you hit that footswitch while you are in DUB mode it first displays 1X and then after a few seconds it displays STOP. So it takes more time before you can empty the loop. Why is this? and shouldn't the right footswitch do the same while in PLAY or DUB mode?

[wedelich]

bodde:

When using the LOOP function of playback mode the manual says that the recorded loop should enter stop mode when the recording is done. But instead of stopping the loop enters play mode just like in AUTOPLAY. So now there is no difference between LOOP and AUTOPLAY. I think it is a bug (?)

I'm not able to reproduce this behavior.  To clarify it should only Stop when Max-Length is reached if PLAYMODE is set to LOOP.  If you use the Left Footswitch to stop the Recording, the Loop will always Play.  It's possible you got out of sync with H9 Control.  To be sure try to change the PLAYMODE parameter directly on the H9.  

bodde:

Also the manual says P: LOOP and AP:LOOP which can be misleading while the playback 'button' in the H9 control displays AUTOPLAY. Better for the manual would be AP:AUTOPLAY I think. (this is a minor thing though).

We needed a way to communicate that they both Loop as opposed to playing once.  The AP stands for Auto Play.  

bodde:

One more thing. Not sure if this is bug though: When using the right footswitch of the hardware while in PLAY mode it displays STOP right away and you can empty the loop by hitting that switch twice after STOP Is displayed. But when you hit that footswitch while you are in DUB mode it first displays 1X and then after a few seconds it displays STOP. So it takes more time before you can empty the loop. Why is this? and shouldn't the right footswitch do the same while in PLAY or DUB mode?

The 1X is sometimes displayed if there was a Speed change, it might be a cosmetic issue, the Looper is still in the STOP state.  For some reason or another the Speed control display is taking precedent over the Loop State Display.  However, it doesn't slow down the actual Empty, just double tap after it says 1X, you'll find that it will just read EMPTY after the 1X goes away.  I'll check out the cosmetic issue though.  

[Bodde]

ok, thanks for clarifying!

When in DUB mode it always displays 1X before STOP. In play mode this doesn't happen. In DUB mode you have to wait for the STOP sign to be able to press again twice to empty the loop. This is making emptying the loop slower I think. Or at least you can not tap the Fw for the 1X disappears (?).

About the P:LOOP. I didn't know it only stopped after the max loop time. I thought it also should stop when you stop recording with the left Fw. My mistake. Can you give some practical use for using the LOOP over AUTOPLAY?

[Bodde]

Forgot to add: the 1X sign is always there when you stop in DUB mode. Not only when you do a speed change like you said. So also when nothing is changed.

[wedelich]

bodde:

ok, thanks for clarifying!

When in DUB mode it always displays 1X before STOP. In play mode this doesn't happen. In DUB mode you have to wait for the STOP sign to be able to press again twice to empty the loop. This is making emptying the loop slower I think. Or at least you can not tap the Fw for the 1X disappears (?).

I can see this happening, I think the dub mode aspect is only when you're hooked up to H9 Control, at that is the only way I can replicate the Dub Mode dependency.  I'm still able to Empty the loop when the display shows the 1X.  You should be able to as well.  A quick test to whether it's empty or not, is to quickly empty it and then press the Left Footswitch to Record before you ever see the Stop.  It should Record, which proves it successfully emptied.  I believe this to be a cosmetic display bug, but I'll dig into it a bit to be sure.  

bodde:

About the P:LOOP. I didn't know it only stopped after the max loop time. I thought it also should stop when you stop recording with the left Fw. My mistake. Can you give some practical use for using the LOOP over AUTOPLAY?

The most practical situation would be where you want several bars (or an exact time) of loop that you don't need to play immediately immediately but want to trigger later in a song. 

[Bodde]

You are right about the 1x display. You can empty the loop but it is not very practical in a live situation if one can not see on the display what's really happening. I always use the H9 control on my laptop also when playing live

wedelich:

The most practical situation would be where you want several bars (or an exact time) of loop that you don't need to play immediately immediately but want to trigger later in a song. 

ok, but then it would be more logical to me if the behavior was the same when using the footswitch to stop the loop. So not only with the loop end time like it is now.

[Bodde]

'Discovered' something else today. When changing the resolution it always changes back to OCTAVES after you have emptied the loop and hit record again. Even when you have saved a preset with say OCT+5th the moment you start recording it jumps right back to OCTAVES. I don't think it is supposed to that.

[wedelich]

bodde:

You are right about the 1x display. You can empty the loop but it is not very practical in a live situation if one can not see on the display what's really happening. I always use the H9 control on my laptop also when playing live

Yeah sorry about that, I'll put it in the bug list for fixing in the next update.  You could always use an Aux switch set to MT if you want to be very sure that it was emptied in the meantime.  

bodde:

ok, but then it would be more logical to me if the behavior was the same when using the footswitch to stop the loop. So not only with the loop end time like it is now.

You can always use the Right Footswitch in any PLAYMODE to stop the recording.  The PLAYMODE specifically defines 3 things with each setting: 

1. how many times the loop plays 

2. what happens at MaxLength

3. The function of the middle button in H9 Control

The Left Footswitch is agnostic to Playmode.  I figured it best to have the Footswitches always be consistent, that way in a crunch they are predictable.   

[wedelich]

bodde:

'Discovered' something else today. When changing the resolution it always changes back to OCTAVES after you have emptied the loop and hit record again. Even when you have saved a preset with say OCT+5th the moment you start recording it jumps right back to OCTAVES. I don't think it is supposed to that.

That is actually how it was intended to work (it's in the user Looper Help file).  It was actually a hard decision to come by, choosing between having an auto Octave switch back or not, but here is why: 

Each way ( 1. auto Octave swtich back, 2. no auto Octave switch back) will always require an extra user step to change the Resolution in the situation where you want to record a new loop and have it playback at the speed you recorded (which I'm assuming is the majority of cases for a Looper in a guitar pedal).  For 1, it the extra user step always occurs after you create a new loop and have to adjust the Resolution to something else.  For 2, the extra step occurs before you want to record a new loop, i.e. put the Resolution back to Octaves, or at least make sure you put the Speed back to 100 or 50, etc.  

During a performance, I believe missing the extra user step for 2 to be more detrimental than missing it for 1.   If you forget to do it for 2, the weird and possibly out of key playback will come as surprise, if you miss it for 1, well, you really don't miss it, because you can do it at any time.  

Therefore, I assume that 2 is the more dangerous path for the majority of users, so I default to 1, with the tradeoff that it's slightly inconvenient for the more tweaker-prone out there.

[Bodde]

wedelich:

Therefore, I assume that 2 is the more dangerous path for the majority of users, so I default to 1, with the tradeoff that it's slightly inconvenient for the more tweaker-prone out there.

I guess I belong to the loop tweaker group! So now you can only use other resolutions besides OCTAVES after you have recorded the initial loop (?). It would be better I think if the resolution state could be saved on the preset. Cause now when want say SMOOTH each time you have to first record the loop and then change the resolution to SMOOTH. When you empty the loop you have to do it all over again.

One other thing: when recording a tempo loop of 8 beats say with two chords from each 4 beats (as an example) when I change to 1/2 speed after I recorded the loop it only loops the first chord (4 beats). When you change to 1/4 speed it only loops the first two beats. On all other loopers I have it loops the whole recorded loop and not half the loop when you go the 1/2 speed. Why is this? Does it have to do with the maximum loop time? Is it only behaving like this in tempo mode?

Don't want to diss the looper in any way. Really love the looper! Because I am a live loop tweaker I just want to know it's full potential and limitations.

[wedelich]

bodde:

I guess I belong to the loop tweaker group! So now you can only use other resolutions besides OCTAVES after you have recorded the initial loop (?). It would be better I think if the resolution state could be saved on the preset. Cause now when want say SMOOTH each time you have to first record the loop and then change the resolution to SMOOTH. When you empty the loop you have to do it all over again.

 

I'll give this (saving the resolution) another think, I didn't think it was possible at first, given the design constraints, probably for some good reason that I knew about then (when I was in the thick of it), that I've since forgotten.  If it comes to me, I might put it in an update, but it probably won't be anytime too soon.  

bodde:

One other thing: when recording a tempo loop of 8 beats say with two chords from each 4 beats (as an example) when I change to 1/2 speed after I recorded the loop it only loops the first chord (4 beats). When you change to 1/4 speed it only loops the first two beats. On all other loopers I have it loops the whole recorded loop and not half the loop when you go the 1/2 speed. Why is this? Does it have to do with the maximum loop time? Is it only behaving like this in tempo mode?

First of all, yes, this will ONLY occur in Tempo mode as long as you're not dubbing.  If you dub in Tempo Mode, it will go the whole loop length at the slower speeds.  (of course this is all in the help file too).  

The reason for this had more to do with locking to MIDICLK than anything else.  We figured the loop would be locking to a beat or MIDICLK that had a solid outside notion of downbeat  and phrase length (in beats), and that this "ground truth" downbeat was agnostic to the speed of the loop.  So, we wanted to make sure the original downbeat of the loop always stayed true.  This was the only way to guarantee a beat-lock, because, if you set it to speeds that don't evenly divide the original length and the let the whole length play out the loop will get out of time quickly.  

Of course, we didn't want the dubbing to be constrained by this Playing feature, so we allow it to dub through.  I also figured dubbing was was the way to get the loop to go out of time if you actually wanted it to do that.  

Since there is really no difference between Tempo Mode and MIDICLK following (Tempo Mode w/o MIDICLK just uses the internal MIDICLK) this carries over even when you're not slaving to MIDICLK.  I honestly didn't have time to come up with a third mode, Tempo Mode using internal MIDICLK, that would do something different.  

All that said, If there is enough support to make it do something different we will, of course, consider it.  I can possibly imagine some compromise where we let it play through all the way on evenly divided loop lengths, but it all gets pretty complicated when you start making too many special exceptions.  

[Bodde]

wedelich:

First of all, yes, this will ONLY occur in Tempo mode as long as you're not dubbing.  If you dub in Tempo Mode, it will go the whole loop length at the slower speeds.  (of course this is all in the help file too).  

  

Thanks again for the explanation!

For me personally it is very confusing and unlike any other looper I own and have tried. Every other looper plays the whole loop in 1/2 speed. It makes no sense to me to have it behave different in play and dub mode. I understand what you are saying but it is very confusing and less practical (for me).

Especially if you switch a lot between play and dub mode like many users do.

[wedelich]

bodde:

Thanks again for the explanation!

For me personally it is very confusing and unlike any other looper I own and have tried. Every other looper plays the whole loop in 1/2 speed. It makes no sense to me to have it behave different in play and dub mode. I understand what you are saying but it is very confusing and less practical (for me).

Especially if you switch a lot between play and dub mode like many users do.

Duly noted…. now that I'm getting some space from rushing to finish a good solid Looper, I'll think about some of these issues and what we should do about them.

Trying to cram all the best looping features in one super-flexible algorithm proved challenging, as there were many competing features and trade-off decisions to be made.  For example, seamless dubbing over the splice often clashed with a solid beat sync (especially with noisy/jittery MIDICLK sources).  Add in the anytime speed changes and non-destructive loop trimming, and you've got a hell of a beast to tame.  As a "tweaker prone" user you're stumbling upon all of the trade-offs rather quickly!   Not that I mind, we appreciate when our users dig in.     

[Bodde]

wedelich:

Trying to cram all the best looping features in one super-flexible algorithm proved challenging, as there were many competing features and trade-off decisions to be made.

Thanks Russel for the great post and help. Really appreciate this and all your work in the looper. The looper is great and is more and better than I ever expected from a two (three with AUX) knob looper!

I can imagine that it is hard to make decisions because you obviously can't do it 'right' for everyone.  Just wanted to let you know that I am really happy with the support I am getting from Eventide.

[Author]

Posts