Let's complain to Roland en masse! (was Re: Boss RC50 delay issues)

["Tom Ritchford" <tom@swirly.com>]

So this is really annoying.

Two big issues with the RC-50.

There are two issues with the RC-50 that undermine this otherwise really useful device.

1. the glitch on first loop.
   
2. the time-stretching artefacts.
   

The time-stretching quality issue is harder to fix, perhaps less important.

Let's look at the second one quickly.  This is pretty bad;  it makes the time-stretching unusable for me at least.  But it's almost usable, others would be fine with it, and it's just a specific sound;  it's consistent.  

But more realistically, fixing time-stretching is hard.  It's DSP.  You need a serious grasp of mathematics.  You can't just add a few if statements and have it all work.  (I still bet I could make it sound better than that if I had a hack at the source code but I always think that...)

The loop glitch is much easier to fix and REALLY annoying.

The glitch is simply silly.  I understand that when the box came out, they had a problem.  But they had a rev. that *almost* fixed the issue, but not quite.  What's with that?  And this _isn't_ a hard issue, algorithmically.  In fact, I don't really have a model of why there's any issue at all.(*)  Still, that's certainly fixable with logic, not DSP -- in other words, you should be able to just "add a few if statements" and make it work.

I understand realtime code is pretty hard in general but I stand by my evaluation that this must be problem that's feasible to solve without too much engineering time.

Power to the people!

So here's my suggestion.  I think we should get together everyone who has an RC-50 and get them all to ask for a fix to BOTH issues -- but making clear that the glitch is the most important one.

The reason we ask for both is that they are then sort of forced to give us one.  :-D  Always ask for more than you hope to get when you're negotiating.

We need to point out that the unit was flawed out of the box, we've stuck with it, and the supposed fix didn't really improve the time stretching, it helped the glitch but it's still there and it's been a long time.

looperglitch.com

think think think.  heh, here's what I'd do.  I'd register a site called looperglitch.com and I'd put just text and embedded youtube videos from tons of musicians with someone demonstrating the problem with the glitch and the time stretching.  Then everyone who owns the unit can contact Roland's tech support and send this URL;  and we can post it to the appropriate music and support groups so it gets some publicity.

I'll bet we could get it on music-thing at least.

Possible ideas for the videos

The videos would be short and sweet;  we need one where you compare the unit's performance with another Looper that does a really good job at it.  

For example you'd compare the Headrush with the RC-50 for the loop glitch, or with the Repeater for the time glitch.  I know it's not entirely fair to use the Repeater, which is "best of show" for time stretching, but we really want to make our point.

The ideal videos would have almost no speech in them.  "This is the headrush.  This is the RC-50.  Headrush. RC-50" (you show the good one first so the contrast is more obvious...)

Sorry for being so dogmatic and etc. in the last text.  Feel free to ignore what I say... :-D

I can do a lot of this.

I can certainly do pretty well all of this, certainly setting up the site, myself.  But there's no point if I'm just some 

I'll try to record some at my gig tonight, actually -- there's a camera there and I'll have all three of those units there to compare set up. 

 It costs nada to have more videos, you should all record some.  I can do a little magic to make sure that they appear in "random order" within each category so everyone gets a shot.

We need people to do this!

It doesn't have to be very many but it has to be more than one lone crank.

(* -- Oh, wait, I do.  In these sorts of machines, you always need to be a little ahead of realtime.  So they represent their sound in chunks of a fixed size for manipulation and then queue these up.  Unfortunately, their queue implementation is lame and doesn't handle this specific case until the currently playing chunk is finished, though it gets the time calculations right.)