Highly Liquid Forum facebook twitter google plus rss feed

Go Back   Highly Liquid Forum > Discontinued Products > MD24

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 02-14-2013, 03:39 PM
carloszkeke carloszkeke is offline
Junior Member
 
Join Date: Feb 2013
Posts: 5
Default Audio channel selector for guitar live performances

Ok guys, I'm a newbie here so I'm going to just spit this out onto the table the best way I can. This is an amendment to my previous post, so I will repeat some info. As a gigging guitar player for 15 years, I moved to putting my sound on stage with multiple speaker enclosures. Both myself and my guitarist, Tony, play through stereo processors. I took it a step farther by adding my new Fractal Axe FXII with the necessary support. I've had a LOT of great comments on the results, but this is not the place to discuss that.
Here's the plan for this project; A Roland FC-300 MIDI foot peddle sends patch change messages simultaneously to both processors. That message is also fed to an MD24, which decodes them and generates an 8-bit word divided up into 4-2 bit signals fed to audio select ICs. This idea came about when, during rehearsal, Tony and I realized that swapping around my 4 available tones, sometimes results in an arrangement that blends better with what he's playing out of his 2 cabinets. The combinations are endless. You can imagine how such an ever changing requirement would be impossible for live shows. A need for a smart audio switcher became obvious. Thanks to the wonderful people at Highly Liquid, this can be achieved much easier than I expected. Here's my first question: How do I (we) design this thing so I can program the MD24 "on the fly"? Meaning, I want the ability to have manual control, during the rehearsal of a song, to punch-up different patterns of speaker locations using a second foot peddle. When I make a decision as to the best sound, I hit the "learn" switch on the foot peddle and the MD24 repeats that any time that patch number is called up. The manual control peddle will require a MIDI CPU. Only in manual mode can an update be performed to the MD24. The way I understand it now, this would require that a SYSEX message be generated for a change in output configuration to take place. I'm at a roadblock !! Any ideas??
Attached Images
 
Reply With Quote
  #2  
Old 02-14-2013, 11:09 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Hi Carloszkeke, welcome to the forum.

Until now, I missed your post from 2/11. Sorry for not responding sooner.

Thank you for posting the diagrams. It will make things much easier to understand. I'll do my best to digest what you are trying to do.

In order to provide a thoughtful response, I am going to have to re-read your posts when I have a little more time to work with. I will follow up soon.

Luckily, I am about to embark on a rewrite of the MD24 firmware. Perhaps some new features will be added that will be of help for this project. You can find that discussion here:

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

I will post more soon. Thanks for your patience!
Reply With Quote
  #3  
Old 02-15-2013, 02:45 AM
carloszkeke carloszkeke is offline
Junior Member
 
Join Date: Feb 2013
Posts: 5
Default Firmware and programming

John, thank you for your reply. An MD24 firmware revision sounds exciting (and necessary) for me to do my own digesting. The truth is, I am approaching this from a purely theoretical standpoint. Many aspects of MIDI word structure and config. programming are foggy at best. I am concerned about one thing; The MIDI word generated by the manual foot peddle (using a MIDI CPU) would have to serve as a realtime controller (irrespective of FC-300 output) and be able to reconfigure the MD24, by simply pressing a single footswitch (learn). Keep in mind, manual mode would not be the primary mode used for live performances. On the surface, I can see that there will be a difference between the structure of the word coming from manual control (MIDI CPU) compared to what the FC-300 generates. I downloaded "MIDImonitor" from the internet to try to understand what part of the patch change message the MD24 needs to process, and what part to ignore (if any). I did not get any useful info from this.(see attached) There are several other concerns that are not directly related to your products that I also welcome advice on, such as using the MD24 output to annunciate(using LCD display modules) the current status of audio distribution (located at the manual foot peddle) The display would follow either mode. Expect more diagrams/dialogue as we get farther into this. Once I am satisfied with the proof of concept phase, I'll be ready to make a purchase and begin prototyping.
Attached Images
 

Last edited by carloszkeke; 02-15-2013 at 02:43 PM.
Reply With Quote
  #4  
Old 02-21-2013, 02:38 PM
carloszkeke carloszkeke is offline
Junior Member
 
Join Date: Feb 2013
Posts: 5
Default Updated block diagram for audio switcher

Ok guys, I'm still wandering in the fog and can't see past the conceptual phase of this thing. I know what I want but I don't have a clue as how to achieve it. John, (or any of you) how do I pair-up a program change with user defined data, and be able to substitute that data from an outside source ON THE FLY?
I made a new drawing in hopes of clarifying the design requirements. Please tell me that I don't have to incorporate an MPU (or two).
Attached Images
 
Reply With Quote
  #5  
Old 02-25-2013, 05:13 PM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by carloszkeke View Post
Ok guys, I'm still wandering in the fog and can't see past the conceptual phase of this thing. I know what I want but I don't have a clue as how to achieve it. John, (or any of you) how do I pair-up a program change with user defined data, and be able to substitute that data from an outside source ON THE FLY?
I made a new drawing in hopes of clarifying the design requirements. Please tell me that I don't have to incorporate an MPU (or two).
Ok. I think I understand pretty clearly what you'd like to do. I'll rephrase it. Let me know if this is correct:

(1) Recall an 8-output "preset" state (collection of on/off outputs to control audio switcher) using a single program change message from the footswitch.

(2) Change individual on/off output states using different messaging (MIDI CC messages), independently of preset. (Instead of logic control, I prefer MIDI control here because of cost advantage and simplicity.)

(3) Change the 8-output state that is stored in any preset "slot" in by using the mechanism in (2) plus an additional "store" command (maybe a special CC command). (Here too, MIDI control is superior because of simplicity and cost.)

The MSA is already in use for audio switching applications, and is probably a better fit for this application than the MD24.

The MSA already does (1) and (2), but as of firmware 3.1, it does them separately and not at the same time. The ability to do both simultaneously has been requested by other users. It would be natural to include (3) to complete the feature.

The messaging required should be easy to generate with an off-the-shelf MIDI foot controller or with a MIDI CPU based DIY controller.

The remaining question is to define the best workflow for "storing" a new preset.

My inclination is keep it as simple as possible. So perhaps the MSA could "listen" for the special "store" CC command. When received, the MSA will take the next program change command and store the current output state to the preset for that program #. Does that make sense?
Reply With Quote
  #6  
Old 02-27-2013, 02:16 AM
carloszkeke carloszkeke is offline
Junior Member
 
Join Date: Feb 2013
Posts: 5
Default We're gettin there

Ok John, You're with me right up to the sequence that stores an updated output configuration (OC). Here's where the difference lies;
1) The current active program is using a previously stored configuration.
2) User switches mode to MANUAL and "experiments" with different output configurations while the original program (patch) remains unchanged.
3) If a new configuration is decided upon, a LEARN, or STORE command is given via a dedicated footswitch.
4) The current program (which never changed) is now permanently paired with the new output configuration.
5) The system automatically defaults back to mode(1) and assumes normal operation. (but with an updated OC)
Reply With Quote
  #7  
Old 02-27-2013, 02:26 AM
John's Avatar
John John is offline
Moderator
 
Join Date: Jan 2009
Posts: 3,007
Default

Quote:
Originally Posted by carloszkeke View Post
Ok John, You're with me right up to the sequence that stores an updated output configuration (OC). Here's where the difference lies;
1) The current active program is using a previously stored configuration.
2) User switches mode to MANUAL and "experiments" with different output configurations while the original program (patch) remains unchanged.
3) If a new configuration is decided upon, a LEARN, or STORE command is given via a dedicated footswitch.
4) The current program (which never changed) is now permanently paired with the new output configuration.
5) The system automatically defaults back to mode(1) and assumes normal operation. (but with an updated OC)
I think this is exactly what is going to be implemented in the new firmware. Please take a look at the MSA firmware version 3.2 preliminary manual that I uploaded earlier today. The details are here:

http://forum.highlyliquid.com/showpo...2&postcount=23

I am going to do my best to get a beta version of the firmware completed quickly.

I'm not sure if you have already purchased the MD24 for your project, but if so, you are welcome to exchange it for an MSA, if that turns out to be a better solution.
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 07:45 PM.


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