Sim'n Tonic Forums

Hello everyone,
I think it would be useful to have more usb midi commands implemented, like muting/unmuting, what do you think?

This would be very helpful for me, in particular if the feature of "Mute following play button" is not going to be implemented in the near future, and maye this would be more easily implemented.

Great little device, BTW, thanks Simon!

Does anyone have any other suggestion, except mute/unmute?

Cheers
Simon

PS: see viewtopic.php?t=232

Muting/unmuting + a few more commands added in Firmware v1.1

I have one: the full-gamut tempo control on CCs 85 and 86 would also be useful to get on a single NRPN, where you pass

1. desired tempo value as an integer between 30 and 400, e.g. 60 gets you 60 bpm
2. tempo value times ten as an integer between 300 and 4000, e.g. 600 gets you 60 bpm
3. tempo value between 0 and 16383, mapping that (logarithmically?) across the whole of Midronome's functional tempo range

The last of these would provide for the greatest granularity of tempo, but I think for most applications No. 2 will suffice, and be easier to document.

I guess you means either option 1, 2 or 3?
These might need to be on another CC as it could be confusing to current users using CC 85 and 86 if it suddenly changes the way it handles the values.

Yes, one of those three suggested implementations, but no, not a CC (128 values possible); I am talking about a Non-Registered Parameter Number (NRPN), supporting 16,384 values in a single message.

Ok I did not know about these - I'll investigate, it does sound a lot better than 2 CCs! Thanks for the suggestion

Hi

I did some investigation, as well as reading the MIDI spec about NRPN.
It sounds too complicated for what it is: the correct way would be to send MIDI CC 99 +98 (NRPN MSB + LSB),
then followed by either MIDI CC 06 + 38 (Data entry MSB + LSB) or MIDI CC 96 or 97 (data increment/decrement).

I doubt anybody would actually use this? Feel free to tell me otherwise

A simpler implementation could be mapping two MIDI CCs, for example CC 110 and 111, values going from 0 to 16383 to a tempo from 30 to 400 (and yes, mapping logarithmically is a great idea ).

Since there has been no interest in this for over a year, I decided to drop this feature for now.

Making a "proper" NRPN sounds unecessary, but we could potentially add two more CC numbers (as written above) to map the whole range 0-16383 to the Nome's tempo range (30-400) logarithmically.

Let me know if this is of any interest

This would make creating MIDI presets for the tempo changes easier, I think. Streamlining that process seems like a great idea.

Well I could add a command to create a preset maybe, that's not a bad idea.
But we already have a lot of commands to set the tempo - why would adding an NRPN help with that?

Simon wrote: ↑05 Dec 2024, 11:47 we could potentially add two more CC numbers (as written above) to map the whole range 0-16383 to the Nome's tempo range (30-400) logarithmically.

Let me know if this is of any interest

Sorry, this was the part I was talking about. Maybe I'm not getting it right, you would add a function to map the whole tempo range from a preset that includes all the corresponding cc numbers?

No worries at all, and sorry for being unclear

I think I got confused between "MIDI Presets" and the Nome Tempo Presets (i.e. viewtopic.php?t=211 ).

What I meant was:

• Right now we have for example CC85 and CC86 which give the tempo (128 x CC85) + CC86
• This means you cannot use a controller to map the whole 14-bit range (16383 values) to the tempo, as for example CC85=4 would be invalid (as it would give 128 * 4 = 512 and that's outside the range)
• So the idea was to add another 2 CCs, say CC108 and CC109 which maps the whole range, and potentially using a logarithmic mapping. i.e.:
  • we are mapping X = (128 x CC108) + CC109 to the tempo range 30-400
  • X=0 gives tempo of 30
  • X=16383/2 gives a tempo of 59
  • X=16383 gives a tempo of 400
  • X=x gives a tempo of f(x) = 30 + (ln(1+x)/ln(1+16383)) * (400-30) (for example)

But anyways - as I've said I doubt there is much interest in this from anyone else...

Ah yes, I understand now. Well, seems like it's not really a wanted or particularly needed option anyway.