* First of all, I'd like to repeat sliding_billy_hamilton's question
in his thread "Missing Stomps (CC's) after PC" :
"I wonder if anyone else is having this problem."
Any other Vetta users around?

* Suppose I add a small delay after sending each PC, in order to give
the receiving gear the necessary(?) time to process the message,
before receiving consecutive CC messages.
I guess most users will agree they should be able to disable this
option? Then the question is: which global setting are you prepared to
give up in favour of this one ?

My proposal is : make "Running Status" for the expression pedals
always enabled - and reuse this global setting to enable/disable the
PC delay. Anyone ever had any problem with Running Status? I guess not...

Another possibility is to get rid of the "Disable taptempo". I
introduced that one because of recurring messages on the forum about a
a "misbehaving" fcb1010, which actually was just the TapTempo system,
automatically sending its messages along with NoteOn messages. Usefull
to keep the global Disable or not?

Well...

I vote for disabling the tap/tempo global disable to
be disabled ;) As I tweak a lot with the expression
pedals.

But please keep the vertion 1.0.2c available
somewhere. It is the best one IMO.

Virgilio



--- ossandust <ossan.dust@...> wrote:

* First of all, I'd like to repeat
sliding_billy_hamilton's question
in his thread "Missing Stomps (CC's) after PC" :
"I wonder if anyone else is having this problem."
Any other Vetta users around?

* Suppose I add a small delay after sending each PC,
in order to give
the receiving gear the necessary(?) time to process
the message,
before receiving consecutive CC messages.
I guess most users will agree they should be able to
disable this
option? Then the question is: which global setting
are you prepared to
give up in favour of this one ?

My proposal is : make "Running Status" for the
expression pedals
always enabled - and reuse this global setting to
enable/disable the
PC delay. Anyone ever had any problem with Running
Status? I guess not...

Another possibility is to get rid of the "Disable
taptempo". I
introduced that one because of recurring messages on
the forum about a
a "misbehaving" fcb1010, which actually was just the
TapTempo system,
automatically sending its messages along with NoteOn
messages. Usefull
to keep the global Disable or not?

--- In fcb1010_uno@..., "ossandust"

<ossan.dust@> wrote:

Hi Chris,

I put this issue on the todo list for a next UnO

version...

Yahoo! Groups Links


fcb1010_uno-unsubscribe@...

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Xavier,

Out of the two possible take always, I'd vote to keep "disable Tap
Tempo messages."

I know you are running out of data memory space. But I assume you
still have plenty of code space. So, I would suggest making this
delay algorithm a little bit smart. Example; If I was controlling
five items with PC messages, I would not want these delays to
accumulate or cascade. I would suggest maybe the delay only occurs
for CC functions and only if preceded by a PC on the same MIDI
channel. I hope I'm making sense. If it's a good idea, then you've
probably already though of it.

As for ripwerx editor implications, I'll reply privately in a few
hours.

Mike Riley

--- In fcb1010_uno@..., "ossandust" <ossan.dust@...>
wrote:

* First of all, I'd like to repeat sliding_billy_hamilton's

question

in his thread "Missing Stomps (CC's) after PC" :
"I wonder if anyone else is having this problem."
Any other Vetta users around?

* Suppose I add a small delay after sending each PC, in order to

give

the receiving gear the necessary(?) time to process the message,
before receiving consecutive CC messages.
I guess most users will agree they should be able to disable this
option? Then the question is: which global setting are you

prepared to

give up in favour of this one ?

My proposal is : make "Running Status" for the expression pedals
always enabled - and reuse this global setting to enable/disable

the

PC delay. Anyone ever had any problem with Running Status? I guess

not...

Another possibility is to get rid of the "Disable taptempo". I
introduced that one because of recurring messages on the forum

about a

a "misbehaving" fcb1010, which actually was just the TapTempo

system,

automatically sending its messages along with NoteOn messages.

Usefull

to keep the global Disable or not?

--- In fcb1010_uno@..., "ossandust" <ossan.dust@>

wrote:

Hi Chris,

I put this issue on the todo list for a next UnO version...

All,

I created a poll...

http://launch.groups.yahoo.com/group/fcb1010_uno/surveys?id=12259307

Hey Virgilio,

"final" version 1.0.2.d is on its way, which has nothing to do with
the current delay discussion - but just fixes a "real" bug noted by
Ed Dixon (see release note, soon to come...)

If the delay thing gets implemented, it will indeed be a separate
version, and I would keep 1.0.2.d available next to it. Maybe, to
minimize confusion, I won't publish it at all, just deliver it "on
special request" for Vetta users - because the issue looks very
specific to me, no need to add yet more confusion in the setup of
this damn pedal.

X.

--- In fcb1010_uno@..., "Virgilio C. Ataide"
<virgilioat@...> wrote:

Well...

I vote for disabling the tap/tempo global disable to
be disabled ;) As I tweak a lot with the expression
pedals.

But please keep the vertion 1.0.2c available
somewhere. It is the best one IMO.

Virgilio



--- ossandust <ossan.dust@...> wrote:

* First of all, I'd like to repeat
sliding_billy_hamilton's question
in his thread "Missing Stomps (CC's) after PC" :
"I wonder if anyone else is having this problem."
Any other Vetta users around?

* Suppose I add a small delay after sending each PC,
in order to give
the receiving gear the necessary(?) time to process
the message,
before receiving consecutive CC messages.
I guess most users will agree they should be able to
disable this
option? Then the question is: which global setting
are you prepared to
give up in favour of this one ?

My proposal is : make "Running Status" for the
expression pedals
always enabled - and reuse this global setting to
enable/disable the
PC delay. Anyone ever had any problem with Running
Status? I guess not...

Another possibility is to get rid of the "Disable
taptempo". I
introduced that one because of recurring messages on
the forum about a
a "misbehaving" fcb1010, which actually was just the
TapTempo system,
automatically sending its messages along with NoteOn
messages. Usefull
to keep the global Disable or not?

--- In fcb1010_uno@..., "ossandust"

<ossan.dust@> wrote:

Hi Chris,

I put this issue on the todo list for a next UnO

version...

Yahoo! Groups Links


fcb1010_uno-unsubscribe@...

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Plenty of code space in eprom indeed, but no processor working
memory left - imagine you have to extend your editor, but you can't
use any global or local variable in you java code... ;-)
( to be correct - for the techies amongst us - I could solve things
by constantly pushing and popping data to the processor stack, but
it's very hard to find out how far you can stretch this without
causing stack overflow )

And now to answer your message:
yes it's a good suggestion, and no I didn't think of that yet.
Actually I was thinking of something much easier to implement : just
add an optional delay after sending PC3. This way, the receiver is
given some time to process PC1,PC2 and PC3, before it receives CC
messages, and there is less accumulation of delay when sending lots
of PC messages.

But I'll first wait for some testing results to have a better idea
about the actual needed delays...


--- In fcb1010_uno@..., "Mike Riley" <the-bug@...> wrote:

Xavier,

Out of the two possible take always, I'd vote to keep "disable Tap
Tempo messages."

I know you are running out of data memory space. But I assume you
still have plenty of code space. So, I would suggest making this
delay algorithm a little bit smart. Example; If I was controlling
five items with PC messages, I would not want these delays to
accumulate or cascade. I would suggest maybe the delay only

occurs

for CC functions and only if preceded by a PC on the same MIDI
channel. I hope I'm making sense. If it's a good idea, then

you've

probably already though of it.

As for ripwerx editor implications, I'll reply privately in a few
hours.

Mike Riley

--- In fcb1010_uno@..., "ossandust" <ossan.dust@>
wrote:

* First of all, I'd like to repeat sliding_billy_hamilton's

question

in his thread "Missing Stomps (CC's) after PC" :
"I wonder if anyone else is having this problem."
Any other Vetta users around?

* Suppose I add a small delay after sending each PC, in order to

give

the receiving gear the necessary(?) time to process the message,
before receiving consecutive CC messages.
I guess most users will agree they should be able to disable this
option? Then the question is: which global setting are you

prepared to

give up in favour of this one ?

My proposal is : make "Running Status" for the expression pedals
always enabled - and reuse this global setting to enable/disable

the

PC delay. Anyone ever had any problem with Running Status? I

guess

not...

Another possibility is to get rid of the "Disable taptempo". I
introduced that one because of recurring messages on the forum

about a

a "misbehaving" fcb1010, which actually was just the TapTempo

system,

automatically sending its messages along with NoteOn messages.

Usefull

to keep the global Disable or not?

--- In fcb1010_uno@..., "ossandust" <ossan.dust@>

wrote:

Hi Chris,

I put this issue on the todo list for a next UnO version...

That (switches in stomp mode) was the only bug...?

mike riley

--- In fcb1010_uno@..., "ossandust" <ossan.dust@...>
wrote:

Hey Virgilio,

"final" version 1.0.2.d is on its way, which has nothing to do

with

the current delay discussion - but just fixes a "real" bug noted

by

Ed Dixon (see release note, soon to come...)

If the delay thing gets implemented, it will indeed be a separate
version, and I would keep 1.0.2.d available next to it. Maybe, to
minimize confusion, I won't publish it at all, just deliver it "on
special request" for Vetta users - because the issue looks very
specific to me, no need to add yet more confusion in the setup of
this damn pedal.

X.

I'll put it in a release note very soon :

following bugs are fixed (no more reported bugs left - except for
the delay thing) :

1. In stompbox mode, the switches (relays) can only be programmed
(to On/Off/"no change") in stompbox patches. The switch settings
stored in regular patches are ignored.

2. In stompbox mode, if you want to edit the setup of a patch, you
have to select the patch and then immediately goto setup (by
pressing the down pedal for 2 seconds - standard procedure). If a
stompbox is selected in between, the patch setup does not work
correctly.

3. In stompbox mode, if you scroll from bank x to bank x+10, the led
of the previously selected patch lights up
For instance : select (non-stompbox) patch 3 of bank 0. Switch to
bank 1 - led3 goes off. Scroll further to bank 10 (displayed as 0.) -
led3 lights up, although the patch is not selected.




--- In fcb1010_uno@..., "Mike Riley" <the-bug@...> wrote:

That (switches in stomp mode) was the only bug...?

mike riley

--- In fcb1010_uno@..., "ossandust" <ossan.dust@>
wrote:

Hey Virgilio,

"final" version 1.0.2.d is on its way, which has nothing to do

with

the current delay discussion - but just fixes a "real" bug noted

by

Ed Dixon (see release note, soon to come...)

If the delay thing gets implemented, it will indeed be a

separate

version, and I would keep 1.0.2.d available next to it. Maybe,

to

minimize confusion, I won't publish it at all, just deliver

it "on

special request" for Vetta users - because the issue looks very
specific to me, no need to add yet more confusion in the setup

of

this damn pedal.

X.

I've voted on having the running status always on (keeping the tap tempo
on/off facility). Running status seems to work well with all of my equipment
(Line6 POD2, Digitech GSP21Pro and AXON NGC60 Guitar to MIDI converter). I
haven't found a need for calculated tap tempo so far (POD has that feature
natively).

Regards

Zsazsi