Duggle

It seems that all the i/o is DIN, so yes j8/9 plus SD card. I seem to recall an example of generating notes with an encoder but you'll need to verify that yourself to be absolutely sure (search the forums etc.) or someone will chime in.... Flashing a bootloader is never permanent (ie occasionally the bootloader version is increased) I don't own an f4 yet, but would assume it's an easy operation.

I googled grandma2 and I see it is some kind of stage lighting controller? The buttons, encoders, and faders all generate midi messages? Then NG is highly suitable. Encoders use DIN, that's 2 pins per encoder. A large number of pushbuttons can be connected with a DIO_MATRIX module (it combines DOUT and DIN functionality on a single PCB up to 16x16 each module, I think). For faders (potentiometers) you'll need analog inputs AINSER64 can handle 64 inputs each module. Naturally, a lot of reading at uCApps is required, it sounds like a large project! edit: You will have to have an SD card attached to the core because this is how you configure NG. (i.e. the defalult.ngc on the card determines how your MIDIBox NG functions)

Hi MIDIBoxers, I'd like to enhance my MackieControl emulation LCD display. The motorfaders, encoders and buttons are provided by my BCF2000 and I use a core with 2x 40*2 CLCD to receive midi thru off the BCF2000 in Mackie mode. The text labels really enhance the BCF2000! I use the logictrl.ngc template with the first 4 EVENT_RECEIVERs commented out because the BCF2000 handles these responses. The unit has been of great service for a long time. I would now like to implement the VU meters as a simple bar graph on the LCD there is plenty of room e.g character below and to the left of the channel label string. Reverse engineering the protocol, I find that the aftertouch message: D0 cv represents the VU metering. c is the mixer channel 0 through 7 v is the VU level 0 to C (D=n/a, E=set clip, F=clear clip) So I'm trying to implement EVENT_RECEIVER(s) but I'm not sure how to access and separate the data fields of cv. There is plenty of RAM available on the core. Help very much appreciated. PS: If I can get this much working I'd probably want to improve it to use 2chars vertically for taller bargraph. [edit] the aftertouch is D0 (rather than B0) corrected definitions for v, according to the NG source code

Ok, so the other end of C9 and R7 connect to ground? What is the voltage that appears on pin1 when you: (a) don't press a key? (b) press a key and hold down hard?

I don't understand either of the questions, sorry. If you do a quick drawing of the setup, scan it or photo it and post it here, I could comment on what you're proposing.

I'd think that the analog output is on pin 3. If you set up the circuit as per the schematic (with same or similar value of resistor), then what is the voltage range max to min on pin 3 when you activate the aftertouch? What is the voltage at rest (key not pressed)? The voltage range that is produced will determine whether you need to scale and offset this signal.

Hi, It comes down to what is the output range of the strip in relation to the input range of the Ain ( I assume 0..5v). So what is the voltage range output of the strip?

What "LF series IC" are you talking about?

Just a gentle bump. I haven't spent more time with this, but I'm confident of getting it to work. TK, is there any prospect of adding core slave IIC transfers to MIOS32?

MIOS Studio can be compiled for any linux environment. However I suspect Linux is not right for you. I use linux in a very minor way. There are lots of in and outs with it generally, compared with Windows and OSX. Unless you really like going on a huge learning curve, or have some other compelling reason for it, my advice is to install Windows 7 on the machine you formerly used with Windows XP (check compatibility with your hardware of course, usually not an issue, but you should check with the manufacturer, if it's a generic machine then you won't have issues). Windows 7 is much more universal (basically everything runs on it) and you can always find suitably dumbed down advice and tutorials for every issue you might encounter, quickly, by googling. Linux is great, but certainly isn't for everyone (contrary to what some enthusiasts like to declare).

I have a MIOS Studio feature request: BTW; the option switches used in command line invocation (I embed them in windows desktop shortcuts) are indispensable to me, they really improve life with MIOS Studio! Anyhow, my feature request is a "quiet mode" switch that suppresses non essential pop up dialogs such as "Rescan MIDI devices.....I have no idea/Understood" and "Batch job complete" etc. Such pop ups are definitely not helpful for an experienced user (who uses invocation option switches).

Thanks for the advice, guys, I'll look into this....

Update: I have implemented the demo master/slave self test mentioned above in a MIOS32 app. The call to the test routine is made from the App init. It returns a successful result (I can see it working with the source level debugger in Eclipse) but shortly after that (before it can print the result to MIOS Studio terminal) it crashes. I guess this underlines the benefit of using only MIOS32 library routines (where possible). The test routine alters settings in the NVIC (nested vector interrupt controller) which might be the source of the problem. I'm using the MIOS32_DONT_USE_IIC switch. I can post code or code snippets if that would help. The code I'm using is from here

I should mention that I'm using STM32 Core. I've found a good code example in the STM32F10x peripheral library 3.3 where the demo sets up I2C1 and I2C2 as master and slave respectively then initiates a read and a write between the ports. This example seems not to be included with the latest peripheral library. I discovered it by googling and it exists in GIThub under a project called "Thinner Client" for anyone interested. It appears that there is almost no difference (if any?) in initialisation calls between master and slave mode. So my question is: Does MIOS32_IIC support slave mode on the core side? The example code above seems straight forward enough to adapt but it would be nice to use the MIOS32 library wherever possible.

That's great, just what I'm after, thanks. I take it that the MIOS32_DONT_USE_* are only referenced in the sources they apply to. Are they listed together anywhere (presumably encased by comment)?

I'm considering an interesting midification. It requires 3 channels of audio bandwidth ADC. I'm using an STM32F103RE soldered to a low cost SMD adaptor PCB. Is it sufficient to #define MIOS32_AIN_CHANNEL_MASK 0 then I am free to call the ADC_*() and DMA_*() peripheral support routines and setup the hardware particular to my needs and define my own interrupt handlers in my own code? I'd also need to do similar thing (i.e custom code overriding MIOS32 functionality) with the 2 channels of DAC as well as a timer/PWM channel. The application has no LCD (I'll use a separate core running NG for the user interface), no SRIO, but will use 2 UARTS for MIDI. The hardware allocations I'll check myself, but I'm mainly asking about how to override/replace the existing software functionality of MIOS32 in those peripherals I'll be using.

Are you suggesting I use a virtual machine in windows to install Ubantu 12.04 and then use it to cross compile MIOS Studio to RPi?

I might buy the win32 RPi cross compiler pre built ($10) and see if it works: here edit: The midi bridge is not required. TTYMIDI is an ALSA midi driver for the RPi UART: here

I've just started using Raspberry Pi and am wondering how feasible it is to compile MIOS Studio for this platform? Of course it would need a serial port driver to work with the Pi's built in UART. It would work with Hairless Midi Serial Bridge (which works great with MIOS Studio, btw) but there's the same issue: it needs to be built for the ARM platform and has various dependencies that make the prospect of a successful build seem a bit daunting. I'm not that experienced with Linux so I thought I'd ask for advice.

To answer the question you'll need to know how the switch matrix is configured in the DX7 (I'd assume circuit diagrams are available on the net though). You'll also need a core and a DIO matrix to make it happen. The pitchbend and mod wheel may require an op amp circuit to shift and scale the right voltage range for the ADC on the core. I bought an original DX7 20 years ago that was about 12 years old at the time. For the last 15 years I've used it as a master keyboard midi controller. I have a sheet of plywood over it with a cut-out for the keyboard keys, pitchbend and mod wheel. This provides a surface for computer keyboard and mouse/trackball as well as other control surfaces. It actually looks surprisingly good and highly functional as a music workstation. I'm using it daily at the moment, and it's done a lot of work over the years. The build quality of yamaha is amazing!

I haven't checked all the connections of your circuit diagram (sorry). But I did look at your schematic in relation to unused pins on the 74HC541. The unused pins are outputs and should be left open not grounded. There a connections to the corresponding input gates from the core. You need to make sure these signals are active (configured as outputs by the firmware) otherwise remove the tracks and connect the inputs to ground (as TK suggested). These tracks (connecting the core to the inputs of unused gates) are not performing any function.

GM5 (up to 5 ins and 5 outs) is good and simple if you can get hold of the chip/PCB (I used the small PCB by TK). The LPC17 core can do 4ins and 4outs and has the option of the routing functionality (if you want that).

TK makes an in depth comment on this issue (in ucapps, I think). Although the transport is much faster (than uart MIDI) there is a lot more processing that goes on at both ends. Therefore, for a simple task such as transmitting notes from a KB probably better to stick to plain old MIDI.