Duggle

I worked around this by triggering a SENDER. EVENT_SENDER id=102 type=SysEx ports=1000001000000000 stream="0xf0 0x00 0x01 0x00 0x01 \ 0x00 0x00 0x00 0x00 10 \ 0x00 0x00 0x01 0x34 10 \ 0xf7" from the NGR: if ^section == 6 trigger SENDER:102 endif The problem is now that there is a strict limit on the length of the Sysex stream. It seems to fail to find the SENDER if the stream is a bit longer than the one shown above. Is there a way of sending larger Sysex messages?

Would it be possible to implement line continuation character in NGR? I'm wanting to send a long Sysex message which I would like to type over multiple lines for clarity. Here's a shorter example: send SysEx OUT3 0xf0 0x00 0x01 0x00 0x01 0x00 0x7f 0x00 0x10 16 0xf7 but send SysEx OUT3 0xf0 0x00 0x01 0x00 \ 0x01 0x00 0x7f 0x00 \ 0x10 16 0xf7 doesn't work.

Sounds like you have success! I have no idea why a HC595 would be bad? Of course having the configuration on the SD Card is essential, as well. If you still want the schematic perhaps PM to Wilba (out of respect for the author). I suppose he has not posted it publicly for some reason or other...

No worries, Zephyrin. Copy and paste just the contents of the grey panel in the link to a plain text editor and save as MBSEQ_HW.V4, then copy it onto the SD Card.

Yes, you will need a MBSEQ_HW.V4 on the root directory of the SD Card. The one for the control surface PCB that you have is: here [edit] Do this first, I think it will all work now.

Hi, I'm not completely sure I understand, but I get it that you have some LEDs not come on, and others are on all the time? I had a problem on mine which turned out to be 1 LED in backwards, which caused several (2, or 3) LEDs to shine constantly! My advise is to carefully check the polarity and orientation of all LED's. I have a circuit diagram that the author sent me that helped me identify the problem. Anyhow, If you check all the LEDs like I said, that should do the trick.

Got code! :frantics: Thanks!

I got my parts for the displays, so I'll integrate and merge the code in each release until a more permanent feature is added. ilmenator, I'll PM you my request for code, thx!!!

Thanks, TK. It happens to be STM32 though I will be testing it on LPC17 later. I'll do some diagnostic debug messages and post back. I had some trouble with USB debug messages in the display driver code interfering with the ability to upload code to the Core. I think this could have been made worse by the large amount of data being sent in the messages. I can always resort to UART midi for the debug messages if I have to.

Rio, If you would like to add 2 midi outs: the buffer is not strictly necessary, I've built 2 SEQ's (V4 and V4L) with MIDI3 in/out and MIDI4 in/out, driving the outs directly from the Core. If MIDI OUT3 and OUT4 is all you want to add, then 4 of 220R and connectors is all you need.

Not quite sure exactly what you mean here. If you nave extra LED's you want to drive then yes, you could connect them to the spare columns of the RGB matrix. To have proper control over the LEDs you'd only connect LEDs to the red columns. I don't know how or if LED rings could be driven this way. Simpler and probably a lot better to add SR's for extra LED rings.

I'd like to set the baud rate on a UART different from the MIDI rate that is default. (I'm developing a display driver). I've found call's to MIOS32_UART_BaudrateSet(..) ineffective. (Sorry I dont recall the value returned). Most of the functions in MIOS32_UART say "Applications shouldn't call this function directly, instead please use MIOS32_COM or MIOS32_MIDI layer functions" I'm finding that setting #define MIOS32_UART2_BAUDRATE 715250 in mios32_config.h works perfectly. I'd prefer to initialise the uart in the driver init call to make it as easy as possible to build this display into an application. What calls do I need to make to set the uart baudrate at runtime?

Yes, the situation evolved during the thread. Correct, and the nice thing is, the configuration variables: sr_dout_sel1, sr_dout_r1, sr_dout_g1, sr_dout_b1 can be assigned to any SR in the DOUT chain. As you may have recognised, 8 rows of 6 has a little less wiring than 6 rows of 8 (8+3*6=26 Vs. 6+3*8=30), though how you plan on routing the wiring, layout etc, can influence which wiring scheme is best for you (they're functionally the same). Note that the second DOUT matrix will have it's own sr_dout_sel1, sr_dout_r1, sr_dout_g1, sr_dout_b1 assignments.

The folder in the repo that has the NGC I linked to is called "templates" I suppose because it is a configuration that provides specific functionality for a purpose, that's all. In a typical situation it would be renamed "default.ngc" and placed in the root dir of the sdcard. My only advice for you at this stage is to read NG related manuals and do some tutorials, look at the Protools manual (sections relating to HUI or control surfaces, etc.) Then come back, with insights, provide some background, your general intentions, etc, and ask more questions.

I'm sorry I'm unfamiliar with the HUI protocols supported by Protools. If you can activate a Mackie mode in Protools then that would be a good start. (In fact the Mackie/Logic template may be the only HUI ngc config that is available at the moment.) If you (or anyone) can crack the Protools protocol and write your own configuration then that would be an achievement because as far as I understand, PT is a "closed" system. (They want you to buy their equipment, so there's no open documentation). I'm really no authority in this area, I'm afraid I'll have to leave it to others to comment further.

The ULN drivers are good to use, but they have a ~=1V minimum output so you can compensate by using a lower series resistor (I used 82 R). You could set up a second DOUT matrix to provide up to another 64 LEDs. The 8x8 matrix I built was quite bright. I made rectangular diffusers out of opal perpex which spread (and de-intensified) the light. I constructed the matrix in a modular fashion: 4 LEDs to a strip of matrix board with cathodes commoned together along the horizontal (a "module") 2 modules for each row of 8 leds (a link connecting the common cathodes) 8 rows in total. the RGB anodes of each LED have 3 pin header pointing in one direction, and 3 wires 10cm long, with a 3 header socket wired to it. columns are formed by chaining tegether the header plug/sockets The output of the ULN pins wired to each row. If you draw diagram it helps to make things clear.

What hardware do you have attached to DIN? [edit] It looks as though you have a generic NGC. You'll need one that supports a particular protocol. Here is an example of a config that provides support for mackie/logic control protocols: here

Can you please post your configuration file: default.ngr from the core sdcard.

Marxon links to a long thread where issues are discovered and resolved, it has a happy ending! A few points in summary: 64 RGB LEDs can be driven by a single DOUTx4 PCB The (4) shift registers of the DOUT are organised:(1) row drivers, (1)Reds, (1)Greens, (1)Blues, assignable on a register, not on a bit level. This 8x8 RGB LED matrix provides at least 64 colours and looks great. I upgraded to a 16x4 matrix by adding 3 more shift registers (7 total), this gives higher duty cycle, more colours, even brighter.

I'm interested in this project. Looks nice! I play music with someone who has a Wavedrum. Is the firmware based on MIOS32?

BL is the backlight driver. IIRC you have other plans for the Backlights (RGB) so don't worry about this for now. The Vo is the contrast bias. If you look on the Core circuit its just coming from a pot. If the contrast is even between the displays you may drive all of them off the core circuit. What precisely do you mean? It does not work at all? If so there is a wiring mistake....

Such a brute force approach of sending all data is impractical as you point out. There may be ways of avoiding this and still getting the utility I was envisioning. For example: Dumping only data for the selected track would cut the amount of data right down. Or maybe it would be possible to request the settings when and as they are required from the control surface side. I'll find out. :smile: I'll get around to playing with this feature as it is now, and if I come up with some concrete suggestions that is easy to implement without side effects then great!

User Error! D'oh :blush: I had Device Id=1 (rather than the default =0) due to an earlier experiment!

I boot up my latest model Mac Mini and I find a sudden failure of MIOS Studio USB communications with 3 LPC17 based Cores. Not a complete loss, the midi monitor on the Mac is seeing input from a midi keyboard forwarded to USB1 in the SEQ's router. But the "Query" button does not work on all 3 devices (KB, NG, SEQ). I've tried rebooting, power cycling the devices, isolating devices, restarting MIOS Studio etc,etc. The task at hand is to reflash the firmware in the SEQ but I can't get that far! The only thing I can think of is an automatic update has caused some nasty change, but I have no idea really.

That's great, it's clear that parameter changes from the UI of SEQ are now sent as they are changed. What about a "state dump" where all parameters are sent (at an appropriate time) to update an external DAW or control surface of all (or rather only those that have changed or were not previously transmitted) controllable parameters? The idea (what I'm considering) is an NG based control surface that has a fairly comprehensive layout of the SEQ controllable parameters. It would be important to have the state of the controls reflect the state of the SEQ.