On July 24, 2006 at 07:48, johnsfine said...
Did you mean "leadin and leadout" or did you mean
"repeat". I'm pretty sure the leadin and leadout
are required for each.
IIUC, you did have leadin and leadout for each
command in all four samples, and you left out
the first repeat part in all four samples. You
varied whether or not you left out the second
repeat part and whether or not you added a little
delay inside the first leadout.
Yes, I meant leadin and leadout. This is new to me and I didn't know whether or not they were require for each--but now I do. :-) Yes, you understand correctly.
I think that's a bug in the Universal Browser.
I didn't notice an explicit mention of the Universal
Browser in this thread. But this is a URC forum,
not a Pronto forum.
Yes. In the top post, I described wanting to do this for an MX-850 as a bit of a work-around for not using a macro, and the success is perfect for that application. However, if the thread has strayed from topic for this forum, I'm sorry. I didn't specifically mention using the Universal Browser, but perhaps should have, because...
The device itself probably doesn't need a repeat
part for the signal. A Pronto is perfectly happy
to use Pronto Hex without a repeat part. But
the Universal Browser won't correctly import Pronto
Hex without a repeat part. I should have mentioned
that earlier and explicitly asked whether the
Universal Browser is involved.
I didn't know about this, but am glad that I now do, in case I need to construct any other codes. :-)
I don't fully understand the transformation you
get when you try to import Pronto Hex without
a repeat part. I'd expect worse results than
you described. But I stil think that bug is the
cause of the repeats that you didn't expect.
I'm sure you're right. I'm still a little confused though--all of the (normal, unmodified) NEC1:64 codes generated by MakeHex have the very same two-bit repeat burst. So what determines whether or not a button repeats?
