Duggle

Ok, thanks, but how do I assign the ^section variable from an encoder? I see plenty examples of static RunSection assignments from pushbuttons but no examples of assigning this value from an encoder? [edit] I suppose I can do my own ^section equivalent by reading the 1st encoder to determine what code get executed (i.e case switch) and the 2nd to determine the velocity. I need to take care of what happens if the 1st encoder is changed during execution etc.

(Btw: thanks for increasing the maximum encoders, it's been working well at this end since I increased this myself.) I've noticed this same problem with my SEQV4 which has the same encoder type just for the data wheel. I've had them lying around since at least 2005. They have an integrated switch. I don't remember seeing this problem with the earlier (2010) MIOS32 firmware experiments of my own (STM32). I can just replace the encoders, and move on from this if there's no easy fix in the firmware. (I'm using 1 in my SEQV4 and only 2 in my NG)

I cannot work out from the written description, or find an example of what I would like to do: To trigger a RunSection from a button, with ^section selected by the position of an encoder with ^value set by another encoder. The usecase is to choose an audition phrase (^section) and then vary the velocity of note ons with another control. Perhaps ^value is not right for this because it gets set once prior to RunSection entry? Can I somehow dynamically change the note on velocity while the phrase is playing? Thanks

Use the "midi socket" looking icon to bring up a dialog to route the midi. It is straight forward to create a "midi through" connection from one port to another. (Look at help or other resources if this is not clear- it is easy) So you have KB connected to a midi in, and a yoke port as out. Now bring up a monitor window to see the data flowing from in to out. Start your host program and set it's midi-in to the yoke port. Try the modwheel from the keyboard that works o.k then try KB all the time looking at the midi in, or out monitor (the midi in and out monitor should show exactly the same). I'm guessing that there are extra midi events going to the host or maybe the same controller events going at a much faster rate that is screwing up your host. BTW; what is your host program?

I have an encoder to send synth patch bank change, its a CC (to avoid confusion I'll call it Sbank). I have an encoder to send a patch change, its a PrgChange message. I have a button to trigger a dump request, it's a sysex message. These controllers are all now working. What I want to have happen is this: When a change of bank is made with it's encoder: Sbank change is sent Whatever value the PrgChange was, it gets sent again (this is what actually changes the patch/bank in the synth) A dump request gets sent (this updates the MIDIbox with all values in the new patch) When the PrgChange encoder is changed: The new PrgChange gets sent A dump request gets sent Can forwarding to SENDER be made to work this way or do I have resort to meta=RunSection:xx or do I need to combine them to do what I described?

I've changed: #define MIOS32_ENC_NUM_MAX 72 from the original value of 65. Btw: No error message at 65 makes sense in light of this. All good now. I'm using a detented encoder which are different from the undetented ones I put on the Fairlightiii PCBs. I'm having trouble getting a really good response from them. ENC type=detented2 seems to be the best, though it still jumps a bit. I'm using enc_speed_mode=Slow:4 which also helps, but is there any other debounce setting I can try? I'd like to use these knobs for patch and bank selectors, with a "detent" per unit of change if that is possible.

The command line parameters are fantastic, they really allow a streamlined workflow when doing intensive NG configurations. Also allows to customise "instances" of MIOS Studio (store the parameters in a shortcut itself, or a batch file) so that MIOS Studio can do different jobs without constantly re-configuring it through the GUI. Highly recommended! :phone:

Well, it's working perfectly now. I had already set up lookup tables that provide a standard way of addressing UI elements e.g. R1C5 means 1st row 5th col, etc. So I just edited this table for the RGB LEDs! As for the SR counting, (real) SR#5 is driving 8 standard LEDs. The control panel's 8 buttons are using fwd_id=LED:33 to fwd_id=LED:40. (I'm still unsure of why 33..40 but it works.) Anyhow maybe there is a glitch in the matrix SR counting. Also the objectives of using the extra 3 SR's on the RGB matrix has been realised: They do look even better than before (which was already very good, btw).

When I had it with sr_dout_r2=6,sr_dout_g2=7,sr_dout_b2=8 I was missing blue. I'll try it, or similar, again and post back if I notice anything different. But now all colours show correctly except the row thing. I'm not requesting a firmware change, just to find out if I've missed something that's easy to fix. As you understand, too much flexibility can be confusing! A lookup table is easy for me. I've done this already when converting the the lre8x2 to be addressed as 2 rows of 8, rather than 8 cols of 2, if you follow. That took a bit to get the Ledrings in the right order, but now it's done I can forget about it completely.

This would be really appreciated! For my current situation, I require an additional 8. That is 64+8. Many thanks.

I've had my 8x8 array of RGB LEDs working perfectly for some time now. The DOUT SR setup being (predictably): DOUT_MATRIX n=1 rows=8 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 sr_dout_b1=4 led_emu_id_offset=1001 The array uses the 1st 4 SR's in the chain. The id's go from 1001 (row1,col1) to 1064 (row8, col8) Now, as I develop the application I realise I have 3 spare DOUT SR's that I could use to change the array into 4 rows of 16. The expected benefits are: more colours (hues) less flicker (1/4 duty rather than 1/8) brighter output So I break the columns in the middle of the array (easy to do, because I constructed the rows as modules, with a plug connection down the columns). Then I wire the new SR's to the disconnected columns. DOUT_MATRIX n=1 rows=4 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_r2=5 sr_dout_g1=3 sr_dout_g2=6 sr_dout_b1=4 sr_dout_b2=7 led_emu_id_offset=1001 This is what seems to work right. The first point of confusion is that sr_dout_r2=5 is actually SR#6 in the DOUT chain as I use #5 to drive 8 standard LEDs. What is the method of counting SR's here? As for the row ordering, I have the row drivers (inverted) connected the same as the 8x8 array (that is unchanged). I did this because the manual says: rows=4: 4 selection pulses are output by the DOUT register specified with sr_dout_sel1. The pulses are available twice: at D7:D4 and D3:D0. I find the ordering of the rows is thus: addressed row LED row lit 1 1 2 5 3 2 4 6 5 3 6 7 7 4 8 8 I admit I'm confused. Is there a simple way to unscramble the rows in the way I declared the shift registers? I don't intend to rewire anything. If I have to, I'll create a lookup table in the macro processor to provide for LEDs in a linear sequence. But I'd rather not have to if there is a way of declaring them that avoids this.

I've added 2 encoders to an additional "control" panel. The shift register is #2 in the DIN chain. There are 4x Fairlightiii PCBs (ENC with n=1..64, sr=5 .. 20 ) they all work perfectly. So I've added: ENC n=65 sr=2 pins=0:1 type=detented2 ENC n=66 sr=2 pins=6:7 type=detented2 EVENT_ENC id= 65 hw_id= 65 fwd_to_lcd=1 chn= 11 type=CC cc=1 range=0:127 ports=1000100000001000 label="^en1" EVENT_ENC id= 66 hw_id= 66 fwd_to_lcd=1 chn= 11 type=CC cc=2 range=0:127 ports=1000100000001000 label="^en2" This is produced when loading: [MBNG_FILE_C:1337] ERROR invalid encoder number for ENC ... n=66' (1..64) If I comment out the line ENC n=66 I don't get the ERROR message, but the remaining encoder don't seem to work. It seems like something is amiss.....

I'm testing everything as thoroughly as I can (win7x64), so I'll report everything I notice: --version does not display if --help is a parameter (gui only) specifying midi in/out port works even on partial name match (but issues a warning), remember to enclose names with spaces in them with quotes ("My Midiport") --device_id did not recognise (I only tried 0, and "0") if --batch appears on command line after --in= and --out= then the console window is empty. --upload_hex== works fine. (I only used current directory as path) --upload_file= (multiple) works great! muliple --terminal= with multiple --wait== all works perfectly. All --gui_ parameters work as expected. I have a strange desktop. It consists of 2x22" flat lcds the left one is landscape, the right one is portrait. Like an "L" rotated left. The --gui_y=0 line is aligned with the top edge of the left monitor, so that the top third of the right monitor is unreachable (would require --gui_y=-400 to locate the gui there). I mention this as an interesting aside, if it bothers me, I'll change my monitor setup! All the --gui_hide_ functions work as expected. This is all just so incredibly welcome! It will really help my workflow in the NG applications development now and into the future. Also using multiple instances for various devices without having to constantly adjust the port and gui settings will be very good.

There is a good example of forwarding a value from Sysex dump to the value in an encoder controlling sysex message parameter change: blofeld.ngc I would like to do a similar thing: forward a sysex dump value via "syxdump_pos=n:p" (Where n is RECIEVER id and p is position in the received dump) However I would like to update my CC encoders from the dump. Reason: Sysex dump of synth patch is much, much quicker and more complete than a controller dump which unfortunately omits some data such as patch name. So now I have to Sysex dump followed by a controller dump which need to be delayed, adding more complexity still. I could convert every parameter to Sysex short message, a big job, and this is much less desirable for automation than CC's.

TK, it looks brilliant, does this mean I have to buy a mac? (Now that is an ugly workaround! :D ) Is there an easy way of using the MIOS Studio console window for feedback? It's seems you've covered things very thoroughly. I could suggest some additional (future) functionality: the ability to specify screen position/size of MIOS Studio windows enable/disable virtual keyboard Window title caption etc. This allows to set up "instances" for different jobs, of which there are quite a few, now. Anyhow this is a very welcome development, let me know if there is any way I can help.

This post is motivated by the desire for simple, fast way of updating certain files in the MIOS Studio File Browser. While it's general use is fairly intuitive, when iterative upload of 3 files NGC, NGL, NGR is required for an intensive NG application development, it begins to seem very tedious. This is a request for a simple command line interface executable from batch files (or cross platform equivalent) to upload files either via MIOS Studio (which would be very nice) or not. Something like MSUpload.exe myfile.ngc default.ngc MSUpload.exe myfile.ngl default.ngl MSUpload.exe myfile.ngr default.ngr There may not be many voices calling for this, but if as it happens, there is the wherewithal to make implementing this, or a similar idea easy, I though I'd put it "out there".

It seems that blofeld.ngc shows exactly how to do this. That is, acquire the starting value from a sysex dump to a control. I'll convert my 10 "Char" knobs to send sysex parameter change instead of Polypressure "CC"s. Does this only work with Sysex controls though? (or can we convert from Sysex dump to CC encoder value) It would be nice to set up the values of the other CC and Polypressure encoders from a Sysex dump rather than controller dump. (Sysex dump is much faster than a controller dump.) [edit] It's working well. I suspect there is a way of achieving name editing with 2 encoders and a button (Cursor,Char, and Enter) which I will look at later on. In the meantime the "10 knob" method works really well!

why thank you! No, it's on the standard controller mapping. I'm using the controller dump sysex request, to try to acquire the values from the patch. I'll revisit the manual and see if there are any variations. This might just do it for me, as I only have to initialise the display with the dumped name, the knobs can take over from there. But is there any way of "updating" the controls to the dumped values (assuming the 10 knob method)? TK, is there something I'm doing wrong in relation to the opening post? Or does it not work like I'm trying to get it to?

Sounds like a great idea! I hadn't though of it being implemented in .NGR, more flexibility and no downside of memory usage, as you state. Great idea with the RGB LEDs, as well, I'd definitely use this.

This applies most to synth editor NG applications. The idea is inspired by the "section locking" feature of this editor:http://ctrlr.org/access-virus-ti-snow/ Put simply it allows to "lock" a section, or group of parameters so that they retain their settings when a new sound is dumped to the editor. E.g you want to keep the effects setting of a particular patch, and hear them on a different patch. For this to work I imagine it would be necessary to optionally define a "lock_group" property to each control. Then by assigning a lock group to a toggle function pushbutton it would be possible to determine if the group of controls "hear" incoming dumps. toggle lock group(s) to lock existing settings initiate control dump edit and save, etc Perhaps have an "invert" function which reverses the toggle state of all locks. This way one could browse effects of different patches on the same patch (to continue the previous example).

I should mention: the names are 10 chars not 12, as I stated. The 10 knob method works for generating a patch name. It appears on the NG LCD and synth display. I use encoder definitions 10 like this: EVENT_ENC id= 5 hw_id= 5 fwd_id=LED_MATRIX:25 bank=2 fwd_to_lcd=1 chn= 1 type=PolyPressure key=112 range=32:127 enc_speed_mode=Slow:4 label="^PnChar1" and label definitions like this: LABEL PnChar1 "@(3:1:2)%c" LABEL PnChar2 "@(3:2:2)%c" LABEL PnChar3 "@(3:3:2)%c" so that each control updates it's own 1 char field of the LCD. The problem I now find is that the Sysex requested controller dump does not include the patchname :hmm: (for some reason!) This is a pity because I was relying a simple pushbutton that requests the dump to initialise the Midibox when beginning to edit a sound. This method works for all the sound parameters I've tried so far.

You need to route the MIDIbox KB to midi-ox then (via midi yoke) to your host. Then you will be able to see (in midi-ox) what the host is receiving (that it cannot handle).

I have a MBHP MIDI Monitor attached to the output of the MIDIbox NG. The first knob shows 10 positions on the Ledrings, but outputs no midi messages. Thy second knob does output midi, on the midimon it shows the string "ATch --- 32||||" through to " "ATch --- 127|||||||||||||||||" which is right, except I was hoping to see the note number change with the first knob. What does --- mean? (It normally shows the note number.) Is there a way to make this work? My idea of how to show the "cursor position" was to forward to lcd the values of the first knob to conditional labels on the LCD row directly below where the patch name itself appears: MyPatchX -------^---- The set of conditional labels would show the "^" in each position of 12. Turning the second knob changes the character. Which begs the question: is there a way of printing the edited character? It also occurs to me that every cursor movement would result in a char being written (can't randomly edit a char in the middle without re-entering the other chars that the cursor addresses) PS if these problems are insurmountable, the data is also parameter mapped and addressable via sysex messages...perhaps there is a smarter way? I suppose I could always resort to the 12 knob method (I do have 64 knobs per bank!)

This applies particularly to the Access Virus family of synths (but maybe others). The characters of the 12 char patch name are addressed by 12 CC# (actually poly aftertouch keynums). Each # corresponds to a message containing a char, byte range 32..127 (ASCII). Rather than use 12 encoders to set each char, I was planning on using 2. #field selector:chars are addressed from key#112 to key#121 EVENT_ENC id=1 chn= 1 type=PolyPressure key=any use_key_number=1 range=112:121 #char selector: ASCII range 32..127 EVENT_ENC id=2 chn= 1 type=PolyPressure key=any use_key_number=0 range=32:127 Will this work? I'll try it and post back.

Try routing CC#1 from the MIOS Studio slider to your host via midi yoke. Same?