Highly Liquid Forum facebook twitter google plus rss feed

Go Back   Highly Liquid Forum > Current Products > MIDI CPU

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 03-07-2013, 03:55 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default Firmware 1.4 Features Discussion

The MIDI CPU, in its current hardware incarnation, is beginning to approach maturity with firmware version 1.3.

However, there may be room for a few extra features. I will post feature requests here for record-keeping purposes. Perhaps some can be implemented and included in a version 1.4 release. Those that can't be implemented will be kept on a list for inclusion in a future product.

Feel free to post feature requests below. I will repost some ideas from the 1.3 discussion that didn't make it into version 1.3.
Reply With Quote
  #2  
Old 03-07-2013, 04:11 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Some ideas from the version 1.3 discussion. All of these are extremely speculative and may have a very slim chance of being implemented.

- MIDI filtering (modifying MIDI input before merging it into MIDI output, probably in response to control terminal input). To make this a flexible and useful feature, it seems like a "can of worms". There is not a lot of free program ROM left on the Rev K MIDI CPU, so this feature might be better off in a dedicated product.

- A "note hold" function for continuous note generation. (There is already a gate function.) I believe that this was a request from a single user. I'm not sure if continuous note generation is a widely used feature.

- Matrixed encoders. Encoders are just pairs of switches, so in theory, a single MIDI CPU could support 64 rotary encoders in a switch matrix.

- MIDI sync output (clock/start/stop/continue), tap tempo, and other sequencing features.

- Sequential data entry using a numeric keypad (eg, enter multiple digits followed by "enter")

- "Device ID" for addressing a configuration sysex message to a specific MIDI CPU in a chain. (As of now, the user must connect directly to the MIDI CPU MIDI In to send it a configuration sysex message.)

- Indirect addressing of MIDI CPU data registers. (yikes!)
Reply With Quote
  #3  
Old 03-07-2013, 04:15 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Also requested recently:

- Generating a sysex message that includes a variable parameter (embedded register value). (discussion)

- Allowing parallel switch matrices for detecting keystroke velocity. (discussion)
Reply With Quote
  #4  
Old 03-07-2013, 04:56 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Additional LED output formats might be nice. Like:

- 7-segment hexadecimal output

- maybe some additional formats. For example, activating a single LED in a group of 8 depending on an integer value from 0-7. This sort of thing would be useful for LED program # indication. For example: this.
Reply With Quote
  #5  
Old 03-08-2013, 06:45 AM
snapperjonno snapperjonno is offline
Member
 
Join Date: Jan 2013
Posts: 84
Default

I'd be keen to be able to utilise the decimal points on 7 digit displays too which are currently unsupported.

In particular it would be great to be able to also use them independently from the digit data - for instance to signal a program change message has not yet been sent.
Reply With Quote
  #6  
Old 03-12-2013, 05:48 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

I think there should be some new data registers that store the most recent program number generated by a matrixed switch. This would provide a simple mechanism to control indicator LED states using matrixed swtiches. Perhaps there could be additional data registers for the last CC message (CC # and value).
Reply With Quote
  #7  
Old 03-12-2013, 06:16 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Another idea: LED output formats that "count from 1" instead of zero.
Reply With Quote
  #8  
Old 03-14-2013, 04:13 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default 1.4 beta 1 posted.

I have posted a new firmware update that includes 3 features:

- New 7-segment LED output format that counts from 1-128 instead of 0-127

- New 7-segment hexadecimal LED output format

- New 3-bit indicator LED output fromat

The update is here:

http://forum.highlyliquid.com/showthread.php?t=935
Reply With Quote
  #9  
Old 03-17-2013, 10:45 AM
bigtim bigtim is offline
Member
 
Join Date: Dec 2012
Posts: 51
Default

I was thinking about some of the functionality that Jonno and I have been working on as part of our guitar effects controller projects and wondered about alternatives to the 'indirect addressing' idea.

I wondered if some additional register manipulation modes for encoder inputs would help do the trick. So the ability to manipulate data registers as well as the encoders own register.

A practical example could be: In my controller I have five footswitches and I want to be able to set the cc number for each of these five.

so if I could have one rotary encoder that cycles through values 1-5, with a sum and a data copy mode, I could have a 7 segment led display the contents of 5 data registers containing my cc numbers associated with the 5 footswitches. A second encoder could then be used to increment the value in the data register that my first encoder is pointing at.

Does that make sense?
Reply With Quote
  #10  
Old 03-17-2013, 07:19 PM
J.D. J.D. is offline
Member
 
Join Date: Jun 2010
Location: Providence
Posts: 57
Default

Quote:
Originally Posted by John View Post
- New 7-segment hexadecimal LED output format
Awesome.

This is one of those things I always thought would be great but never asked for.

Last edited by J.D.; 03-17-2013 at 07:22 PM.
Reply With Quote
  #11  
Old 03-18-2013, 07:58 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default 1.4 beta 2 posted.

I have posted another update (1.4 beta 2) and new version of the manual:

http://forum.highlyliquid.com/showthread.php?t=935

New in this version:

- 7-segment LED output formats now control the 7-segment character "decimal point" based on bit #7 of the LED state register. (inspired by this discussion) This is a little bit tricky to use, since bit #7 is always clear for analog input and encoder input. The data register copy and bit clear/set/toggle control terminal modes can be used to work around this issue.

- The MIDI CPU can now generate sysex messages that contain a variable value from a MIDI CPU data register. (Previously, the MIDI CPU could only generate sysex messages with fixed contents.) See the new control terminal modes 5Dh, 5Eh, and 5Fh.

Last edited by John; 03-18-2013 at 08:05 PM.
Reply With Quote
  #12  
Old 03-18-2013, 08:13 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by bigtim View Post
I was thinking about some of the functionality that Jonno and I have been working on as part of our guitar effects controller projects and wondered about alternatives to the 'indirect addressing' idea.

I wondered if some additional register manipulation modes for encoder inputs would help do the trick. So the ability to manipulate data registers as well as the encoders own register.

A practical example could be: In my controller I have five footswitches and I want to be able to set the cc number for each of these five.

so if I could have one rotary encoder that cycles through values 1-5, with a sum and a data copy mode, I could have a 7 segment led display the contents of 5 data registers containing my cc numbers associated with the 5 footswitches. A second encoder could then be used to increment the value in the data register that my first encoder is pointing at.

Does that make sense?
Hi Tim, thanks for the comment. I think what you are saying makes sense. I am starting to think more about applications like this.
Reply With Quote
  #13  
Old 03-20-2013, 02:16 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default 1.4 beta 3 posted.

The latest update, 1.4 beta 3 is now available, along with a new version of the manual:

http://forum.highlyliquid.com/showthread.php?t=935

Starting with this version, the MIDI CPU saves the data register config in a new format. You will save yourself some headaches if you reset the MIDI CPU data register config immediately after upgrading. I have linked a sysex message to accomplish this. (This is also described in step #10 of the upgrade procedure in the new firmware user manual.)

http://support.codeandcopper.com/hl/...onfig-Init.syx

In this update:
  • The way that the global variables work for switch matrix note velocity, CC "on" value and CC "off" value has been changed.

    Before, there were specific control terminal modes and sysex config messages dedicated to these variables. I have eliminated these.

    Instead, the variables occupy new multipurpose registers 1Eh-20h. To change the variables, simply change the value in these registers. The registers are also subject to initial, min, and max values via the data register configuration sysex message.

  • There are now analog and encoder modes that allow manipulation of data registers, similar to what was already possible using logic input.

  • There are additional new multipurpose registers 21h-29h that can be assigned functions in future firmware updates.

Last edited by John; 07-16-2013 at 08:41 PM.
Reply With Quote
  #14  
Old 03-20-2013, 05:32 PM
bigtim bigtim is offline
Member
 
Join Date: Dec 2012
Posts: 51
Default

Wow, amazing fast work John!

I am glad now I have been slow in ordering my enclosure I think you just saved my drilling lots of holes, made my control system a lot simpler and made a couple of CT's available.

Amazing support and customer service from you once again!

Thank you!
Reply With Quote
  #15  
Old 03-20-2013, 11:09 PM
bigtim bigtim is offline
Member
 
Join Date: Dec 2012
Posts: 51
Default

ooops it seems I may not have thought my suggestion through fully.

When I came to write the code I keep coming up against the need for indirect addressing. The problem is that even with the new encoder modes I cannot avoid the problem that I am trying to vary which register I want to read/or write to and with direct addressing I cant think how to do this.

Heck I hope I havn't wasted your time, I am sure the additional modes will have many uses. Time to get some sleep and see if I can think any more clearly in the morning.
Reply With Quote
  #16  
Old 03-21-2013, 12:55 AM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by bigtim View Post
ooops it seems I may not have thought my suggestion through fully.

When I came to write the code I keep coming up against the need for indirect addressing. The problem is that even with the new encoder modes I cannot avoid the problem that I am trying to vary which register I want to read/or write to and with direct addressing I cant think how to do this.

Heck I hope I havn't wasted your time, I am sure the additional modes will have many uses. Time to get some sleep and see if I can think any more clearly in the morning.
Indirect addressing is not out of the question, I suppose. That could be a use for one of the new registers. (Something like, put a register address in 29h. Then, reads/writes to 29h actually go to the register thus pointed.)
Reply With Quote
  #17  
Old 03-21-2013, 06:37 PM
bigtim bigtim is offline
Member
 
Join Date: Dec 2012
Posts: 51
Default

John, that would be absolutely the ideal solution for my 'problem'.

I am still dragging my heels on the enclosure (busy at work and actually playing the guitar lol) and the bottom line is I do have a configuration that works perfectly well (the indirect addressing is just slightly more elegent) so for sure no rush on my account
Reply With Quote
  #18  
Old 04-03-2013, 05:34 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by bigtim View Post
John, that would be absolutely the ideal solution for my 'problem'.

I am still dragging my heels on the enclosure (busy at work and actually playing the guitar lol) and the bottom line is I do have a configuration that works perfectly well (the indirect addressing is just slightly more elegent) so for sure no rush on my account
Tim, I will see what I can do to get this in.
Reply With Quote
  #19  
Old 04-03-2013, 05:36 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Another feature idea:

Configuring certain registers save their value when the MIDI CPU is powered down.

I could probably make it so that each "multipurpose" register can optionally do this.
Reply With Quote
  #20  
Old 04-03-2013, 10:18 PM
bigtim bigtim is offline
Member
 
Join Date: Dec 2012
Posts: 51
Default

I Like the idea of the multipurpose registers being able to hold their values, very neat idea.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 10:26 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.