Bc2000 (for the BCF2000 & BCR2000)

Wow. I've read that first section four times and I understand less  
each time. I fear that if I continue, all things I think I understand  
will reveal themselves as unintelligible.

Otherwise it seems to make sense, I just don't know enough about  
Mackie HUI sysex, auto-trigger, MCU mode etc to be much help.

For a file viewer/prompter, I would suggest:
- let the application manage and display the docs in its own window,  
rather than open dozens of helper apps and windows.
- decide on a subset of formats to support, eg start with plain text  
and html and do pdf later.

Then you could take the following coding approach in Java:

- receive MIDI message, map to a 'location' string and media type.
- choose a viewer depending on type, eg html or text.
- create or reuse a JFrame to hold the document that is being viewed,  
then add viewer.

For HTML viewing this is as easy as:

String location;
JFrame frame = new JFrame("my viewer window");
URL url = new URL(location);
JEditorPane text = new JEditorPane(url);
text.setEditable(false);
frame.getContentPane().add(new JScrollPane(text));
frame.setSize(500, 500);

etc. PDF requires a third party library - several open source ones  
are available.
You could quite easily add a resource type for system commands, to  
launch an arbitrary command and let it do it's thing. Closing/ 
controlling the command will be tricky to impossible though.


The mapping configuration could contain:
- the type of MIDI message, cc, noteon, sysex
- MIDI channel
- MIDI message value (in the case of sysex this could maybe be a  
regular expression)
- resource type: text/html/pdf etc.
- resource URL

So for example, when a cc1 with value 64 is received on channel 1,  
open the html file sheetmusic.html at anchor 'chorus':
cc1	1	64	html	file://sheetmusic.html#chorus

Just my tuppence, of course.


I realise I've probably muddled things more by talking Java at you,  
though if anyone decides to venture down this path I hope the info  
will be useful.


cheers,

/m


On 26 Mar 2008, at 11:42, goyya76 wrote:
> Hi guys,
>
>
> > This what I thought was required, if not perhaps Goyya can expand on
> > what he wants.
>
>
> here we are: the basic idea is a standalone app that can prompt on  
> its GUI informations read from a file when receiving a MIDI  
> message; different MIDImessage = different file, of course.
>
>
>
> I'll try to summarize what has come out till now (long post, thanks  
> for being patient!) -  right now,  I see 4 steps/possibilities…  
> from my point of wiew, getting the first two done would already be  
> a great result (and maybe not too difficult)!
>
>
>
> 1) BCR/BCF software GUI (my first thought):
>
> ·        the GUI is a BCR/BCF image, under each knob/fader/button  
> (not moving ones, just a fixed image) there's a  text box
>
> ·        the file is FUNCTION.txt (or .xml, …) and contains a list  
> of the FUNCTION parameters, and the relative physical BCR/BCF  
> control (for example encoder 1 = track 1 volume, encoder 2 =track 2  
> volume)
>
> ·        the MIDI messages are...lots of options here:
>
> Mackie HUI sysex, namely those who contain the name of the active  
> FUNCTION (which is  displayed in the middle of Huskervu, BCF view  
> or whatever, and can be the mixer, insert1 fx, a VSTi, etc);  this  
> sysex have to be interpreted  (Huskervu source code can help i  
> suppose) andautomatically triggers the associated FUNCTION.txt file
> o     CC, program changes, etc; in this case a mapping between the  
> CC and the correct file should be provided, the file triggering is  
> not automatic, but for example you could have different soft labels  
> for each BCF/BCR preset
>
>
> The midi message triggers the FUNCTION file and the FUNCTION  
> parameters names are displayed in the text boxes under the relative  
> physical controllers.
>
> This app would  need just MIDI IN, to receive the trigger CC or the  
> feedback from the host (the "auto-trigger mode" would work with  
> every host supporting the Mackie HUI protocol, hosts with  
> configurable remote control could use "the trigger CC" mode).
>
>  It would probably seem needless if you use a BCF in MCU mode + LCD  
> emulator, BUT if you don't have a BCF and/or program the controller  
> by yourself (we've got the great Art Hunkins examples here on how  
> to program a BCR to freely emulate MCU functions) or use host like  
> Cubase that lets you configure their remote control setup  it would  
> be damn useful…and it could work for whatever hardware controller too!
>
> If I understand correctly, this basic app wouldn't be very  
> difficult to implement, and would not need complex stuff like JUCE,  
> just some Java… it's worth noting that all the MIDI programming  
> would be done on the BCF/BCF and/or in the host.
>
>
>
> 2) A prompting system and/or score manager for performers of all  
> kinds (Steve's idea):
>
>
>
> The GUI would just be a panel to set up MIDI input and assign MIDI CCs
> The file is a pdf, doc, jpg, etc file
> The MIDI message are…well, whatever!
> MIDI messages trigger the "open file" function of the correct  
> software, and maybe other functions, like page down for example  
> (just think:  you have a song scored in pdf, and the relative midi  
> file playing in the the host; just insert a CC when you have to  
> "turn page", and Adobe Reader does it for you – cool!)
>
> This function could be a part of option 1), I guess…
>
>
>
> 3) An evoluted BCR/BCF software GUI
>
>
>
> Adding moving knobs to the GUI – they receive feedback from the  
> host (again, following the Mackie protocol or a generic feedback)
> Adding support for vstxml file:  some host support them, they allow  
> to change the order of VST/VSTi parameters and to change their  
> names to something meaningful if needed; that's useful to put the  
> VST parameters in the same order they appear on the VST GUI (which  
> isn't always the case) – so actually encoder 1 will move (left to  
> right) the first knob of the VST GUI , encoder 2 the second and so  
> on…the vstxml could be used also by the BCR/BCF software GUI to  
> display parameters name, keeping everything coherent
> The JUCE pack would maybe come handy for knobs? I suppose this step  
> is quite more complex than the first two….
>
>
>
> 4) A soft BCR/BCF:
>
>
>
> Adding midi out
> All the programming is done in software (you just use preset-1 on  
> th physical controller):
> BCR/BCF control via MIDI the GUI knobs, which outputs custom MIDI  
> messages/sysex (maximum flexibility, multiple messages per knob,  
> one shot CC + continuous CC for a knob)
> Support for presets and remote preset changing via MIDI
> Support for  "multiple pages" presets (see Asseca's mGUI on www dot  
> asseca dot com – I use it and took some ideas from it),  ie if a  
> soft synth has 70 params,  it's relative preset has two pages – of  
> course, midi remote page switch!
> Are we getting into science fiction with this??
>
>
>
> Hope I didn't forget something….
>
>
>
> Ciao,
>
> Francesco (Goyya)
>
>