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
  #41  
Old 07-22-2013, 03:43 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Another possible feature:

Allowing matrixed switches to generate output in a different-CC-value-for-each-switch arrangement.

A helpful feature to pair with this would be "CC value remapping".

Inspired by this thread:

http://forum.highlyliquid.com/showthread.php?t=1096
Reply With Quote
  #42  
Old 10-15-2013, 01:18 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Bug fix required: the MIDI CPU does not read encoders as well as it should.
Reply With Quote
  #43  
Old 10-15-2013, 03:08 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Another nice feature would be to allow potentiometer or encoder input to trigger sysex messages as required here:

http://forum.highlyliquid.com/showthread.php?t=1153
Reply With Quote
  #44  
Old 10-18-2013, 09:20 PM
snapperjonno snapperjonno is offline
Member
 
Join Date: Jan 2013
Posts: 84
Default

Hi John,

I see here that Tim has already been asking about something that has been on my mind for some time with regard to the MidiCPU being able to respond to MIDI IN messages and would like to include my scenario in the discussion to see if it might be possible:

I am using the CPU to send program change messages to software applications to change presets and display the number of the chosen preset on a 3 digit 7 segment display, but suffer from the situation that if the preset is changed in the software itself rather than via the CPU, the CPU still displays the last number it sent and cannot update itself to reflect the change and is therefore out of sync with the software... (hope that makes sense!)

I was hoping that if the CPU could accept and respond to incoming MIDI messages it could update the display to reflect the external change, but in writing this I'm beginning to realise that it's probably not that simple because it would also of course rely on the software generating a MIDI message at the change which probably doesn't happen...

Probably wishful thinking (unless you can think of any way to achieve this..?!)

Cheers,
Jonno
Reply With Quote
  #45  
Old 11-21-2013, 04:58 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

It would be nice if the MIDI channel jumper setting was available in a data register. In response to requests like this:

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

It would also be nice if a global MIDI channel setting could come from a data register, rather than from the MIDI channel jumper setting.
Reply With Quote
  #46  
Old 11-21-2013, 05:09 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by snapperjonno View Post
Hi John,

I see here that Tim has already been asking about something that has been on my mind for some time with regard to the MidiCPU being able to respond to MIDI IN messages and would like to include my scenario in the discussion to see if it might be possible:

I am using the CPU to send program change messages to software applications to change presets and display the number of the chosen preset on a 3 digit 7 segment display, but suffer from the situation that if the preset is changed in the software itself rather than via the CPU, the CPU still displays the last number it sent and cannot update itself to reflect the change and is therefore out of sync with the software... (hope that makes sense!)

I was hoping that if the CPU could accept and respond to incoming MIDI messages it could update the display to reflect the external change, but in writing this I'm beginning to realise that it's probably not that simple because it would also of course rely on the software generating a MIDI message at the change which probably doesn't happen...

Probably wishful thinking (unless you can think of any way to achieve this..?!)

Cheers,
Jonno
I agree about this feature being useful. Unfortunately, the MIDI CPU wasn't really designed with this type of application (effectively, a MIDI "closed loop" with state feedback from another device) in mind. I still may be able to make some rudimentary features that relate to this type of application, but I'm not sure if/when or how good they will be. The current design of the MIDI CPU is close to "maxed out" based on some early design choices and hardware limitations.

I'm not really sure yet where things will go.
Reply With Quote
  #47  
Old 11-27-2013, 06:22 PM
snapperjonno snapperjonno is offline
Member
 
Join Date: Jan 2013
Posts: 84
Default

Is that a glint in your eye..? The conception of MidiCPU v.2 perhaps!!!
Reply With Quote
  #48  
Old 02-04-2014, 06:43 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Another request, probably not viable until there is an updated MIDI CPU design, is adjustable debounce for switch and logic inputs.
Reply With Quote
  #49  
Old 02-08-2014, 01:13 AM
Synthetech's Avatar
Synthetech Synthetech is offline
Moderator
 
Join Date: May 2012
Location: USA
Posts: 711
Default Hi and Low nibble for sysex Raw data byte

can there be a feature to split the raw data byte?

In this section...

3.2.11 Logic Input Trigger: SysEx Raw Data Byte

mm ------------------ d0 Meaning-------------------------- d1 Meaning
5Eh ----- Data Register Address for Data Byte---------- Ignored


can there be a mode that takes a data register in d0, split it's value up?.

so say d0 = reg. 11h

the current value in 11h is 18h.. so you make two bytes out of one.
In this case the low nibble byte is 08h and the high nibble byte is 01h

So my final sysex msg would be something like

F0 40 00 60 10 09 01 08 F7
This message would set my Kawai K3's VCF Cutoff to value "24".


the two red numbers are the value 18h stored in reg. 11h.
the fragment is before them.. I did not need any data beyond my hi/low nibbles.. it just needs to be closed with F7

any chance we can support this? a lot of older gear had this split nibble system.
maybe use d1 as a way to trigger the mode? 00=whole byte, 01= split byte, 02 = inverted split byte (it would be 08 01 instead of 01 08)

if we could support it, I could probably design an encoder that would trigger a CT to increment the Raw data byte in the register used, then send the sysex msg.
I had the idea to decode the encoder with a "D" FF, then pulse a 4066 to pass the G signal to the CT, just as if a switch was pressed for a moment.
Then cascade events... incr. register, perform Fragment Sysex commands.. repeat until the register's data maxes out or wraps around to 0/127.
Use a second CT for the decrement of the register value..



Can you please elaborate how the sysex fragment system works. . is it done in layers? thus you must always have at least the first or last three layers.. or does it matter and you can split them across layers.
Any specific order?

Thanks!

Last edited by Synthetech; 02-08-2014 at 01:16 AM.
Reply With Quote
  #50  
Old 02-19-2014, 07:18 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by Synthetech View Post
can there be a feature to split the raw data byte?

In this section...

3.2.11 Logic Input Trigger: SysEx Raw Data Byte

mm ------------------ d0 Meaning-------------------------- d1 Meaning
5Eh ----- Data Register Address for Data Byte---------- Ignored


can there be a mode that takes a data register in d0, split it's value up?.

so say d0 = reg. 11h

the current value in 11h is 18h.. so you make two bytes out of one.
In this case the low nibble byte is 08h and the high nibble byte is 01h

So my final sysex msg would be something like

F0 40 00 60 10 09 01 08 F7
This message would set my Kawai K3's VCF Cutoff to value "24".


the two red numbers are the value 18h stored in reg. 11h.
the fragment is before them.. I did not need any data beyond my hi/low nibbles.. it just needs to be closed with F7

any chance we can support this? a lot of older gear had this split nibble system.
maybe use d1 as a way to trigger the mode? 00=whole byte, 01= split byte, 02 = inverted split byte (it would be 08 01 instead of 01 08)

if we could support it, I could probably design an encoder that would trigger a CT to increment the Raw data byte in the register used, then send the sysex msg.
I had the idea to decode the encoder with a "D" FF, then pulse a 4066 to pass the G signal to the CT, just as if a switch was pressed for a moment.
Then cascade events... incr. register, perform Fragment Sysex commands.. repeat until the register's data maxes out or wraps around to 0/127.
Use a second CT for the decrement of the register value..



Can you please elaborate how the sysex fragment system works. . is it done in layers? thus you must always have at least the first or last three layers.. or does it matter and you can split them across layers.
Any specific order?

Thanks!
Hi Synthetech, I'm sorry for the slow response.

Yes, the sysex system is designed to work across multiple layers.

So if you have a switch on CT 1, you would use layers like this:

Layer 0: Mode 5Dh to send sysex "begin fragment". This results in the MIDI CPU sending F0h to begin the message, followed by zero or more fixed bytes from the sysex buffer. So the resulting hex output might be:

F0 01 02 03 04 05

Layer 1: Mode 5Eh to send a single data byte. This would be the contents of any MIDI CPU data register (with bit #7 always set to 0). So, if register 11h is used, and it contains the value 33h, then the resulting hex output is:

33

Layer 2: Mode 5Fh to send zero or more fixed bytes from the sysex buffer, followed by F7h. For example:

06 07 08 F7

So, when the switch on CT 1 is pressed, it will generate a sysex message like:

F0 01 02 03 04 05 33 06 07 08 F7

...assuming that register 11h contains 33h.

You could use the same approach but with 4 layers to get two variable bytes in the middle of the sysex. Does that make sense?

Here's some example code:

Set up the first 16 bytes of the sysex buffer (bytes 0 thru 15, or 00h thru 0Fh). I arbitrarily chose values:
Code:
F0 00 01 5D 04 07
60 51 42 63 54 45 66 57 48 69 5A 4B 6C 5D 4E 6F
F7
Control terminal layer 0. CT 1 sends "sysex begin fragment" using bytes 2-5 of buffer:

Code:
F0 00 01 5D 04 01 00
01 00 5D 00 02 04
01 01 7F 00 00 00
F7
Layer 1. CT 1 sends a single data byte using register 11h as the source.

Code:
F0 00 01 5D 04 01 01
01 00 5E 00 11 00
01 01 7F 00 00 00
F7
Layer 2. CT 1 sends a single data byte using register 12h as the source.

Code:
F0 00 01 5D 04 01 02
01 00 5E 00 12 00
01 01 7F 00 00 00
F7
Layer 3. CT 1 sends the "sysex close byte":

Code:
F0 00 01 5D 04 01 03
01 00 5F 00 00 00
01 01 7F 00 00 00
F7
At runtime, if register 11h contains 27h and register 12h contains 28h, pressing the switch at CT1 will generate:

F0 42 63 54 45 27 28 F7
Reply With Quote
  #51  
Old 02-19-2014, 09:45 PM
Synthetech's Avatar
Synthetech Synthetech is offline
Moderator
 
Join Date: May 2012
Location: USA
Posts: 711
Default

Thanks for the reply John.

I follow what you are explaining on how to include a 2nd byte, but how can I get a whole byte split to the two registers?

so when I go past 0F in the 11h reg.(for example), I need it to carry over to reg. 12h an increment of 1 byte..

so when i start, 11h is 0F and 12h is 00.

add 1 to 11h.. 12h increases by 1 and 11h goes to 00

so by adding one, 11h is 00 and 12h is 01 and stays 01 until 11h goes past 0F again.. which would cause 12h to become 02 and 11h goes to 00h again... this goes on up to 12h is 07 and 11h is F.

How can I get this carry over to happen?

Otherwise, I am stuck only incrementing to 0F and must stop there or use a 2nd controller to make 12h increase by just one and then use up the next 16 values in 11h...

Hope this makes sense...
Reply With Quote
  #52  
Old 03-28-2014, 12:34 PM
Eric Lauzier Eric Lauzier is offline
Junior Member
 
Join Date: Feb 2014
Posts: 6
Default Documentation discrepancy

Hi guys, I think there is a few errors in the firmware 1.4 documentation.

The "factory defaults" for Data registers mention these values:
Figure 4.3-2: Factory Default Data Register Configuration
1D 0F 00 7F 00 Configuration Layer Control Register 1Dh: ii = 0Fh.
1E 7F 01 7F 00 Multipurpose Data register 1Eh (matrix note velocity):
ii = 127, mn = 0, mx = 127, rr = 0.
1F 7F 00 7F 00 Multipurpose Data register 1Fh (CC "on" value):
ii = 127, mn = 0, mx = 127, rr = 0

also:
29 00 00 28 00 Indirect Pointer register: ii = 0, mn = 0, mx = 28h, rr = 0.

But step 10 of the firmware update does this:
10. If updating from version 1.3 or earlier, power up the MIDI CPU, and send the following SysEx
message: F0 00 01 5D 04 04 03 00 00 7F 00 04 00 00 7F 00 05 00 00 7F 00 06 00 00 7F 00 07
00 00 7F 00 08 00 00 7F 00 09 00 00 7F 00 0A 00 00 7F 00 0B 00 00 7F 00 0C 00 00 7F 00 0D
00 00 7F 00 0E 00 00 7F 00 0F 00 00 7F 00 10 00 00 7F 00 11 00 00 7F 00 12 00 00 7F 00 13 00
00 7F 00 14 00 00 7F 00 15 00 00 7F 00 16 00 00 7F 00 17 00 00 7F 00 18 00 00 7F 00 19 00 00
7F 00 1A 00 00 7F 00 1B 00 00 7F 00 1C 00 00 7F 00 1D 0F 00 0F 00 1E 00 00 7F 00 1F 00 00
7F 00
20 00 00 7F 00 21 00 00 7F 00 22 00 00 7F 00 23 00 00 7F 00 24 00 00 7F 00 25 00 00 7F
00 26 00 00 7F 00 27 00 00 7F 00 28 00 00 7F 00 29 00 00 7F 00 F7
Reply With Quote
  #53  
Old 04-03-2014, 03:35 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by Eric Lauzier View Post
Hi guys, I think there is a few errors in the firmware 1.4 documentation.

The "factory defaults" for Data registers mention these values:
Figure 4.3-2: Factory Default Data Register Configuration
1D 0F 00 7F 00 Configuration Layer Control Register 1Dh: ii = 0Fh.
1E 7F 01 7F 00 Multipurpose Data register 1Eh (matrix note velocity):
ii = 127, mn = 0, mx = 127, rr = 0.
1F 7F 00 7F 00 Multipurpose Data register 1Fh (CC "on" value):
ii = 127, mn = 0, mx = 127, rr = 0

also:
29 00 00 28 00 Indirect Pointer register: ii = 0, mn = 0, mx = 28h, rr = 0.

But step 10 of the firmware update does this:
10. If updating from version 1.3 or earlier, power up the MIDI CPU, and send the following SysEx
message: F0 00 01 5D 04 04 03 00 00 7F 00 04 00 00 7F 00 05 00 00 7F 00 06 00 00 7F 00 07
00 00 7F 00 08 00 00 7F 00 09 00 00 7F 00 0A 00 00 7F 00 0B 00 00 7F 00 0C 00 00 7F 00 0D
00 00 7F 00 0E 00 00 7F 00 0F 00 00 7F 00 10 00 00 7F 00 11 00 00 7F 00 12 00 00 7F 00 13 00
00 7F 00 14 00 00 7F 00 15 00 00 7F 00 16 00 00 7F 00 17 00 00 7F 00 18 00 00 7F 00 19 00 00
7F 00 1A 00 00 7F 00 1B 00 00 7F 00 1C 00 00 7F 00 1D 0F 00 0F 00 1E 00 00 7F 00 1F 00 00
7F 00
20 00 00 7F 00 21 00 00 7F 00 22 00 00 7F 00 23 00 00 7F 00 24 00 00 7F 00 25 00 00 7F
00 26 00 00 7F 00 27 00 00 7F 00 28 00 00 7F 00 29 00 00 7F 00 F7
Hi Eric, thank you for much for pointing that out. The matrix velocity and CC values in particular are important to fix. I have uploaded a new user manual that I think removes those errors.
Reply With Quote
  #54  
Old 04-21-2014, 03:58 PM
Jim McDougall Jim McDougall is offline
Moderator
 
Join Date: Aug 2009
Posts: 395
Default Dynamic Midi Channel

It would be really helpful if a register could be used to store a midi channel number and then in the midi messages retrieve the midi channel from that register. Right now midi channel can come from the jumpers but currently this is only read at boot so this cannot be changed dynamically and the other option is hard coded in the message. Having the ability to retrieve from a register would open things to dynamic midi channel assignments and I suspect that is should be a relatively easy function to add. I have a new project in mind that this would simplify.
Reply With Quote
  #55  
Old 04-24-2014, 01:05 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by Jim McDougall View Post
It would be really helpful if a register could be used to store a midi channel number and then in the midi messages retrieve the midi channel from that register. Right now midi channel can come from the jumpers but currently this is only read at boot so this cannot be changed dynamically and the other option is hard coded in the message. Having the ability to retrieve from a register would open things to dynamic midi channel assignments and I suspect that is should be a relatively easy function to add. I have a new project in mind that this would simplify.
Hi Jim,

Let me see what I can do.

It's great to hear from you!
Reply With Quote
  #56  
Old 05-04-2014, 06:13 PM
Jim McDougall Jim McDougall is offline
Moderator
 
Join Date: Aug 2009
Posts: 395
Default Midi jumpers

I am a little confused about the jumper settings as I know in the past there were threads where we could use a switch to set the midi channel from the jumpers. For clarification, is the jumper setting only read at CPU boot or is it read at each message send ?

I have started another project that I will start to document in a new thread, but I need to be able to alter the midi send channel via external control. If I can hook the midi jumpers to a 4066 then I can change the jumper settings dynamically.
Reply With Quote
  #57  
Old 05-12-2014, 03:21 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by Jim McDougall View Post
I am a little confused about the jumper settings as I know in the past there were threads where we could use a switch to set the midi channel from the jumpers. For clarification, is the jumper setting only read at CPU boot or is it read at each message send ?

I have started another project that I will start to document in a new thread, but I need to be able to alter the midi send channel via external control. If I can hook the midi jumpers to a 4066 then I can change the jumper settings dynamically.
When the channel is taken from the jumper, it is calculated anew for each message send. So your idea to change the setting dynamically via the 4066 should work fine.
Reply With Quote
  #58  
Old 05-20-2014, 11:53 AM
lokki lokki is offline
Member
 
Join Date: May 2014
Posts: 31
Default

Quote:
Originally Posted by Jim McDougall View Post
It would be really helpful if a register could be used to store a midi channel number and then in the midi messages retrieve the midi channel from that register. Right now midi channel can come from the jumpers but currently this is only read at boot so this cannot be changed dynamically and the other option is hard coded in the message. Having the ability to retrieve from a register would open things to dynamic midi channel assignments and I suspect that is should be a relatively easy function to add. I have a new project in mind that this would simplify.
i second that! is this planned for 1.4 final? would it be an extension of mode 47h, so that one can use register values for note number, velocity and channel? this would be great!!!
Reply With Quote
  #59  
Old 07-14-2014, 03:55 AM
Michaela Joy Michaela Joy is offline
Junior Member
 
Join Date: Jul 2014
Posts: 1
Default

Does the MIDI CPU allow keyboard splitting? If not, that would be a great mod to add. Most MIDI keyboards allow you to select either the lower zone, upper zone, or both zones simultaneously. Each zone can be programmed with it's own MIDI channel. In the area that the zones overlap, the MIDI CPU would send both layers simultaneously. (that would allow layering of synths.)

IMHO, this would be an awesome addition to the firmware.

EDIT: I just noticed that the hardware has switches (jumpers) for selecting the MIDI channel.
Oh well...I ranted for nothing.

Last edited by Michaela Joy; 07-14-2014 at 03:59 AM.
Reply With Quote
  #60  
Old 07-28-2014, 03:13 AM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by Michaela Joy View Post
Does the MIDI CPU allow keyboard splitting? If not, that would be a great mod to add. Most MIDI keyboards allow you to select either the lower zone, upper zone, or both zones simultaneously. Each zone can be programmed with it's own MIDI channel. In the area that the zones overlap, the MIDI CPU would send both layers simultaneously. (that would allow layering of synths.)

IMHO, this would be an awesome addition to the firmware.

EDIT: I just noticed that the hardware has switches (jumpers) for selecting the MIDI channel.
Oh well...I ranted for nothing.
Michaela, I am glad you discovered that keyboard splitting is already possible. Welcome to the forum.
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 12:19 AM.


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