Final design questions

[Nomical]

TK: I already know some of the answers, but since the 'accident' on Monday, i'll repost my (long) questions just in case you or anyone else still has some new ideas or solutions. Or just in case someone else has a use for some answers given to my questions for his own project.

Thanks for the replies in the original post.

I'm about to finish the design of my MIOS based DB50XG project and i have some final questions.

1: How do use the RS232 interface together with the normal MIDI I/O, without losing the normal MIDI I/O functionality? Do i have to use 2 LTC modules, 1 LTC module and swap the IC's when needed or by a different method?

2: How do i make a direct TTL connection between the CORE module and my own DB50XG module?

3: Which wirings/cabling can or can't be bundled together? Is it only necessarry to separate the digital and analog wires?

4: What would be the maximum length of ALL the different wirings/cables? I already know the maximum length between 2 DIN modules shouldn't be greater than 1 meter to avoid any problems.

5: What's the difference between the SIL headers and 'white headers' on TK's CORE module? And where can i get these? Is it only possible to buy them at stores like Farnell and Reichelt, because my local electronics shops don't have other types of headers besides the SIL type.

6: Does anyone have a tested (and postitively approved ;D ) shematic for a headphones circuit which signal(s) have to be taken from the already existing line outputs?

If i do not want volume control for the headphones, just the output which is controlled by the main volume of the application (like on commercial synths/samplers etc by Roland/EMU/Yamaha etc), would that change the circuit very dramatic?

7: Which IC's are recommended for opamp circuits? These will be used for the above application, the line outputs and the headphones circuit.

8: Does anyone have some clear info on Star-like wiring and for which wirings/cabling it is necesarry?

9: I can use 8 bankstick IC's of 512 at the same time, right? Do these IC's get a 'number' so MIOS understands which one is which? And how many times can data be written to and from these IC's?

10: What would you think is best and what would you prefer? Putting ALL parameters that are in use (system and channel/part parameters) for 1 channel/part in 1 setup and switch between them (16 of them) by swapping from and to banksticks? Or only the channel/part dependent parameters in 1 setup and leave the 'system' parameters in the PIC's RAM? Or maybe some different approach?

11: Has anyone tried to swap the 7805 for a PT5101N?

Someone told me this would solve all the heat problems that COULD occur when using a 7805.

Datasheet (PDF): PT5101 Datasheet

See also here

12: @TK: Why is a hardware reset (caused by the circuit attached to pin 26 of the DB50XG) necessarry for the DB50XG?

13: @TK: Could you take a look at this please? It's about wrong pinnings descriptions for the waveblaster connector on/for the DB50XG. Can you confirm which pinning is correct, since you build an external unit yourself back in the days?

14: @TK: The name of my project will be TK50XGM... ;D

[TK.]

Does anybody have a copy of my answers from yesterday?

Best Regards, Thorsten.

[Nomical]

Does anybody have a copy of my answers from yesterday?

Best Regards, Thorsten.

I also changed some of the questions and i've also modified and added questions after you posted TK ;D

[Guest cem3340]

Nomical, I have built around a dozen midi to waveblaster interfaces over the last 5 or so years and can confirm for you that the information at the very top of the page you linked is the correct pinouts. Building an inteface for midi for these cards is a snap :) and the beauty of the waveblaster spec. is that ALL waveblaster addon cards can be run standalone..eg Rolands GM, DB50xg etc. The only downside is most waveblaster addons are midi receive only thus if you do any realtime patch editing, all the data must be stored off from the card.

I am interested to see how you go with this project as I have a prototype unit which does pretty much what you are aiming for. I never completed it but oneday... ::)

I have all of the QS300 patches stored in eprom and stream the sysex data as required down to the DB50xg.

Works well.

cheers

[Nomical]

Nomical, I have built around a dozen midi to waveblaster interfaces over the last 5 or so years and can confirm for you that the information at the very top of the page you linked is the correct pinouts.

Ah, ok! Thanks for this info, it's just what i needed ;D

Building an inteface for midi for these cards is a snap :) and the beauty of the waveblaster spec. is that ALL waveblaster addon cards can be run standalone..eg Rolands GM, DB50xg etc.

In my own standalone project this will be more difficult i think, because the MIOS based interface will be tuned for XG (which is superior to and backwards compatible with GS/GM) and especially for the DB50XG. In the future i wish to implent GS/GM modes, which will solve this problem though.

The only downside is most waveblaster addons are midi receive only thus if you do any realtime patch editing, all the data must be stored off from the card.

I don't think that's going to be a problem for me, because the DB50XG will be controlled intirely by the MIOS based interface, so any real-time editing will be generated by MIOS and therefor i can store these changes into a bankstick or i can record them via the midi out of the MIOS interface into for example a sequencer. I think... ;D I have to test all of this yet. Let's first try to finish the code for the PIC ;D

I am interested to see how you go with this project as I have a prototype unit which does pretty much what you are aiming for. I never completed it but oneday... ::)

In the future when everything is tested and all, i'll post the zip files containing all necesarry files to recreate my design.

I have all of the QS300 patches stored in eprom and stream the sysex data as required down to the DB50xg. Works well.

cheers

What's the use of/for this? All QS300/TG300B patches are already on the DB50XG card, why store them to an eprom?

I already was planning to implent a QS300/TG300B mode in the future which can be turned on/off via the (LCD) menu.

[Guest cem3340]

QS300...The full QS300 mode on the DB50xg is different to the TB300b mode you mention, due to an oversight by Yamaha. At the time the DB50xg was released, the QS300 workstation was Yamaha's flagship keyboard. The DB50xg chipset was a derivative of the chipset used in the QS300. When the engineers at Yamaha finalized the chip design for the DB50xg, they forgot to disable the "full" QS300 compatability mode of the cards chipset. If you have studied the way the XG chips generate a sound you will see it is an amalagamation of a number of wavetable based techniques. In many ways it is very similar to Roland's LA based synthesis but is expanded so as FM type sounds can also be easily generated. In basic XG mode, you are limited to four operators (basicly wavetable oscillators) that can be "connected" in various ways. You are limited though to a maximum of 2 "operator sets) in parallel. In true QS300 mode this limit is removed and allows 4 operators stacked in parallel with obvious benefits...some very complex sounds can be created. QS300 pads for instance are hugely lush and full with much more depth than basic XG patches. I am not sure what you mean by QS300 patches are already stored on the card?..TB300 mode is not QS300 mode..remember, the QS300 mode was not advertised by Yamaha, it was stumbled upon by ppl studying the midi implimentation chart. To use the QS300 mode you must set the card via sysex commands, then download the QS300 sysex patch dumps to it (32 at a time). These are stored in the DB50xg's ram until of course you overwrite them or power down the card. When you get it all set up, test the TB300 and QS300 modes and you will see thay are different.

Yamaha was very embaressed by this "oversight" by their engineers and the chipset was quickly modified to disable the QS300 mode...try it on a later model XG card..you will see TB300 mode is still there..QS300 mode isnt. (even the top of the range card cant do it!!) For about 5% of the cost of their flagship product, users could access the rich sound of the QS300 (albiet without the sampling, sequencing etc) Also the DB50xg is FULLY editable. That is you can construct completely new patches for it in QS300 mode (just like a standard synth) but as the unit is not battery backed and the fact you can not sysex dump from it, all patch data must be handled by an external device (hard or soft) and dumped to the card when needed. The eprom wavetable set contains basic saw, square waves etc...stack 4 oscillators with saw and square, slightly detune them and get some of the fattest basses you will hear.. ;D This is what has made the DB50xg a very much sought after unit.

As to why I store them on eprom...I have the full QS300 patch sysex dumps stored there...that way I can call up any QS300 patch at will (these are default patches that came with the QS300). Takes about 2 sec's to transfer from eprom to DB50xg.

As a side note, originally when reviewed the DB50xg impressed the reviewers but they all complained of the high signal to noise ratio. This was not the fault of the card...moreso the fault of the parent card it was plugged into. Through a good amplifier when connected as a standalone device, the DB50xg is as good as any other Pro audio device with regards SN. A number of Pro music ppl I have modified cards for are blown away by how powerfull and how much sound can come from such a small box....QS300 brass sounds are really something ;D

hope this info helps someone

[TK.]

So here the extracts:

1: use a multiplexer or use two AND gates and switch the lines with

a free pin of the core module

2: PIC Rx -> XG Tx,

  PIC Tx -> XG Rx,

  PIC ground -> XG ground

3: don't mix analog with digital wires

4: the maximal length of the whole shift register chain shouldn't

  be longer than 1m. Longer lines could also work, but I cannot

  guarantee this -> try it out!

5: quality...

 

8: required for analog signals only

9: use MIOS_BANKSTICK_CtrlSet to address the BankStick, the

  manufacturer guarantees 1 million write cycles for every

  single byte, but in practice it's even more (10 million+++)    

10: has to be evaluated by yourself. Suggestion: save the most

   frequently used parameters of all channels in RAM, and

   the more exitic parameters (Fx setup, drum parameters)

   in BankStick

12: all logic circuits require a reset for a proper startup

Best Regards, Thorsten.

[Nomical]

[edit2] Now that i see my message in preview mode, i can conclude that's it's probably to big ;D

[edit1] When i finished typing the following questions and re-read them, i knew i was asking/talking about the same thing in very long and the same type of questions in different forms. ;D

I would like to apologize for this in advance, since i am really making an attempt to ask something what is not easy for me to explain in simple words and short sentences.

Since TK told me that sysex is a (often real-time) continious message i wondered something.

If i would assign a certain sysex string to a certain function which is displayed on the LCD, would it be possible to send a sysex string for every increment or decrement value i input with an encoder and this would mean that i can hear the difference this sysex message has on the sound in real time for every 'step'(defined size) up or down i make with a certain encoder? (Because i'm triggering the 'to be changed' sound/voice with an external sequencer)

In a attempt to really make sure people understand what i'm talking about ;D. As an example:

I want to change for instance the cutoff frequency of some sound. On the display is shown a value of 200 Hz (Doesn't really matter what the value is as long as there is a change).

Will the value that's needed in the sysex string for the change in cutoff be taken from the value that's shown on the LCD?

This value that's shown on the LCD would be stored in a pre-defined location of the RAM in the PIC, right?

So every change i make to the value on the LCD, would be audible instantly because of the sysex string that's sent for EVERY increment or decrement that's given by the last known value in comparison to the change in value by the encoders...?

I can't find the answer although it has been given. I Must be an idiot for not finding it.

What's the time needed for the sysex to execute what it should do? I already known there sometimes should be a difference in time between certain sysex commands like 50 ms or something.

How much time in total would it take for (In this order also):

1) The LCD to shown the value that's caused by a (up OR down) movement of an encoder.

2) To take the value that's shown on the LCD after this movement, put this value to a assigned bit of a certain assigned sysex string and let me hear the difference it has on the sound (because i'm externally triggering it)?

Or:

If i sweep the encoder from full left to full right, would i hear the difference that's caused by every step that's been made by the encoder and is displayed on the LCD and has a sysex string based on this value for every 'step'/value change?

Or would all these sysex messages take to long to hear the change instantly? And if so, would i have to make any change of a parameter be executed by a 'enter' command (dedicated 'enter' button ;D)?

These questions go beyond the things a i've read and learned so far. This doesn't mean this is the end for my understanding of things i have to overcome. If i understand what i'm trying to say in the above questions, then my way of understanding of how i have to program the sysex control enviroment into a MIOS based application would be greatly improved/increased.

And this would make me very happy! ;D

Sorry for the VERY LONG descriptions/questions.......

Thanks

[Nomical]

QS300...The full QS300 mode on the DB50xg is different to the TB300b mode you mention, due to an oversight by Yamaha. At the time the DB50xg was released, the QS300 workstation was Yamaha's flagship keyboard. The DB50xg chipset was a derivative of the chipset used in the QS300. When the engineers at Yamaha finalized the chip design for the DB50xg, they forgot to disable the "full" QS300 compatability mode of the cards chipset. If you have studied the way the XG chips generate a sound you will see it is an amalagamation of a number of wavetable based techniques. In many ways it is very similar to Roland's LA based synthesis but is expanded so as FM type sounds can also be easily generated. In basic XG mode, you are limited to four operators (basicly wavetable oscillators) that can be "connected" in various ways. You are limited though to a maximum of 2 "operator sets) in parallel. In true QS300 mode this limit is removed and allows 4 operators stacked in parallel with obvious benefits...some very complex sounds can be created. QS300 pads for instance are hugely lush and full with much more depth than basic XG patches. I am not sure what you mean by QS300 patches are already stored on the card?..TB300 mode is not QS300 mode..remember, the QS300 mode was not advertised by Yamaha, it was stumbled upon by ppl studying the midi implimentation chart. To use the QS300 mode you must set the card via sysex commands, then download the QS300 sysex patch dumps to it (32 at a time). These are stored in the DB50xg's ram until of course you overwrite them or power down the card. When you get it all set up, test the TB300 and QS300 modes and you will see thay are different.

Yamaha was very embaressed by this "oversight" by their engineers and the chipset was quickly modified to disable the QS300 mode...try it on a later model XG card..you will see TB300 mode is still there..QS300 mode isnt. (even the top of the range card cant do it!!) For about 5% of the cost of their flagship product, users could access the rich sound of the QS300 (albiet without the sampling, sequencing etc) Also the DB50xg is FULLY editable. That is you can construct completely new patches for it in QS300 mode (just like a standard synth) but as the unit is not battery backed and the fact you can not sysex dump from it, all patch data must be handled by an external device (hard or soft) and dumped to the card when needed. The eprom wavetable set contains basic saw, square waves etc...stack 4 oscillators with saw and square, slightly detune them and get some of the fattest basses you will hear.. ;D This is what has made the DB50xg a very much sought after unit.

As to why I store them on eprom...I have the full QS300 patch sysex dumps stored there...that way I can call up any QS300 patch at will (these are default patches that came with the QS300). Takes about 2 sec's to transfer from eprom to DB50xg.

As a side note, originally when reviewed the DB50xg impressed the reviewers but they all complained of the high signal to noise ratio. This was not the fault of the card...moreso the fault of the parent card it was plugged into. Through a good amplifier when connected as a standalone device, the DB50xg is as good as any other Pro audio device with regards SN. A number of Pro music ppl I have modified cards for are blown away by how powerfull and how much sound can come from such a small box....QS300 brass sounds are really something ;D

hope this info helps someone

I've been reading about the QS300 sysex commands to control the QS300 voices and as far as i've understood (from the Beggar's Guide deluxe version) these sysex messages consist of sysex dumps rather than sysex strings, because all voice data/parameters for every element HAS to be sent in one sysex message/dump which is build up from more than 50 bytes which takes up a lot of space and time.

If i would make a QS300 mode into my DB50XG project: How would this affect realtime control when it comes to editing the voices when triggering them via an external sequencer to hear the difference?

[TK.]

I'm wondering why you are asking such questions before experimenting with MIOS in order to realize that this is no issue... ;-)

It depends on the used synthesizer if you will hear every single step or not, it's related to the type of parameter, the resolution, the sound engine implementation, the interpolation algorithm, etc... I don't remember the exact behaviour of the DB50XG, but I guess that most parameters can be smoothly changed without clicks. At least the CC controllable parameters, but also some SysEx parameters (I never controlled all of them)

Of course, you have to save the current value of a parameter in RAM. The USER_ENC_NotifyChange function will be triggered on every encoder event (increments, decrements) and gives you an incrementer which has to be added to the value (7, 8, 16, ... bit doesn't matter). Mostly the incrementer is +1 or -1, but the value can also be greater when:

• you are using a different speed mode
  
• one of your function allocates the CPU for some time, so that the encoder handler received some increments which haven't been notified via USER_ENC_NotifyChange yet
  

Even if the incrementer is > 1, let's say 4 or 6, and you are sweeping from the min to the max value very fast, you won't hear a clicking sound, unless the synth engine implementation is too poor (like Quasimidi stuff for example).

Regarding the execution times: with MIOS absoltely no issue since this is an interrupt & event driven system, optimized especially for such applications. When you send a SysEx stream of (lets say...) 10 bytes by using the MIOS_MIDI_TxBufferPut function, your program will continue immediately and the string will be sent in background. Every MIDI byte takes 320 uS, 10 bytes are taking 3.2mS - enough time to do a lot of other things in parallel - printing out a 16-character message and a value on LCD takes maybe 200-300 uS, reading the characters from a bankstick will increase the time, but it will be still less than the transmission of a MIDI event, so that you can ignore it!

MIDIbox SID is a nice demonstrator how smoothly parameters can be changed via SysEx - the control surface sends SysEx messages to the slaves and they are processing the incoming data in realtime.

Best Regards, Thorsten.

[Nomical]

I'm wondering why you are asking such questions before experimenting with MIOS in order to realize that this is no issue... ;-)

......

Best Regards, Thorsten.

;D I know you said this before and must be thinking what a stubborn guy i am... ;D

I'm sorry about asking before experimenting, but i just think it helps the way i think about building up the application in assembler language. I'm starting the LCD Menu interaction, reading a lot about sysex of the DB50XG and it just makes my descisions easier if i know what is possible and not and how things are handled.

I want to program it the way i want it to instead of having to change code afterwards (has to be done afterwards anyway, but i would like to minimise this as much as possible).

I like collecting as much info in advance before starting to build the code, so if i run into some problems or alternatives i know what possibilities i have of adapting it. Instead of just trying it until it works.

I guess this has to do with my education, because that's the way they tought me to work and think in chemistry.

I want to make a very nice interface (frontpanel and MIOS application), that features no bugs or anything.

I'm also building it for you TK! ;D

Thanks for all the answers to my questions. Maybe they seem not so important, but they really helped me TK.

[EsotericLabs]

2: PIC Rx -> XG Tx,

  PIC Tx -> XG Rx,

  PIC ground -> XG ground

Best Regards, Thorsten.

Hello,

I'm very new to this andI also want to connect a db50xg clone to the midibox lpc 17 core. Do I understand correctly? Just wire J4b sd to midi in on the sound board? (and sc to midi out on the board. ( an make a psu and audio in/ out hardware etc). Or would I need some kind of buffering or anything in between? I wil make a midi 3 in /out as in the core module page on us apps.de

I hope it's not a very silly question, I searched the forum, but I did not find an answer on my level of understanding of midibox.

Thanks a lot for helping me out!

[Shuriken]

TTL Midi Out won't be necessary. I have to come across the first board that supports Midi Out.

Edited September 16, 2012 by Shuriken

[EsotericLabs]

TTL Midi Out won't be necessary. I have to come across the first board that supports Midi Out.

Thank you Shuriken,

It appears that the nec xr385 uses midi out as a midi thru. Not sure whether it is necessary, don't think so.

But how to connect the card to the core? Just wire midi out 4 (from the j4b port) to the midi in of the soundboard? Or is it better to put the midi out / midi in infra with the 220Rs, an opto etc?

Functionally it looks redundant: TTL-> midi -> TTL, but on the other hand, this may be necessary for decoupling? Please shine your light on this.

[Shuriken]

Thank you Shuriken,

It appears that the nec xr385 uses midi out as a midi thru. Not sure whether it is necessary, don't think so.

But how to connect the card to the core? Just wire midi out 4 (from the j4b port) to the midi in of the soundboard? Or is it better to put the midi out / midi in infra with the 220Rs, an opto etc?

Functionally it looks redundant: TTL-> midi -> TTL, but on the other hand, this may be necessary for decoupling? Please shine your light on this.

Looks like you are right. I only checked my Korg en Terratec board, but with the NEC it seems to be used. I would do TTL. However i am not sure if that will work with the LPC17 as it's 3,3V. The boards expect 5V TTL.

So port J4B and then connect SD & SC and VS. You should connect VS to digital ground.

Edited September 16, 2012 by Shuriken

[EsotericLabs]

Looks like you are right. I only checked my Korg en Terratec board, but with the NEC it seems to be used. I would do TTL. However i am not sure if that will work with the LPC17 as it's 3,3V. The boards expect 5V TTL.

So port J4B and then connect SD & SC and VS. You should connect VS to digital ground.

That's very useful info, thank you.. I could up the level to 5v with a simple opamp? And there is a level conversion link on the lpc17 page on ucapps.de I ll check that out as well.

[sparx]

This is all really interesting stuff and has appeared just at the right time.

I've been playing with a DB60XG clone and LPC17 core for a few months and am just about to revisit the project with ideas as to the end result.

Hopefully this will be a starting point, at last, for everyone in uapps land.

Take a look at the GM Voice here:

GM Voice

This circuit works, I have built and tested it.

In the next couple of days and if there is any interest, I will post more stuff in probably a new thread as to what I have been doing and what I want to do with the board.

In the meantime, have a think about what you want to do with yours and post back here.

Regards

S

[EsotericLabs]

@shuriken: I found on Wikipedia that in TTL, anything between 2V4 and 5V. So I'm hopeful that it will work just fine.

@sparx,: yes please post what you have on lpc17 and th xr385. I'm interested already! Cool project!

[sparx]

Martijn, using an op amp is not the way to go here, all that is needed is a couple of inverters.

Take a good look at the design of the GM voice, this uses two NAND gates with inputs tied together.

I am in the process of uploading all my stuff on this so far, if you can't wait, google "sparx plays up the junction".

Give me a day or so and I'll post it all.

Regards

S

[sparx]

Double post.

Edited September 17, 2012 by sparx

[Shuriken]

@shuriken: I found on Wikipedia that in TTL, anything between 2V4 and 5V. So I'm hopeful that it will work just fine.

That would be my suggestion.

Martijn, using an op amp is not the way to go here, all that is needed is a couple of inverters.

Take a good look at the design of the GM voice, this uses two NAND gates with inputs tied together.

I am in the process of uploading all my stuff on this so far, if you can't wait, google "sparx plays up the junction".

Give me a day or so and I'll post it all.

Regards

S

The NAND gates in the GM Voice do the TTL to Midi conversion. However Martijn is looking for a TTL Level Gate something like this to get from 3,3V to 5V TTL.

Edited September 17, 2012 by Shuriken

[EsotericLabs]

The NAND gates in the GM Voice do the TTL to Midi conversion. However Martijn is looking for a TTL Level Gate something like this to get from 3,3V to 5V TTL.

But when I look closely at the lpc17 schematic, J4A has 5V as Vd and not 3V3. The schem is not explicit about J4B's Vd, but my multimeter says also 5V (well, 4V97..). J4B.Sc and Sd also have pullup resistors to 5V. Other ports (J5, J16) do have Vd at 3V3 but not J4A/B.

Then, is the double NAND necessary when J4B (midi 4) is running at 5V? It's no problem to find a proper IC (a 74HC14?) and put it in between for buffering and tightening the TTL signal. But just for learning purposes: is it really necessary?

Thank you for replying!

I'm gonna build an awesome hardware midi file player with an SD card and dedicated hard coded midi control for my Axon Ax100 mkII and midi floorboard. And 3-port-midi-switchrouter mode with onboard hardware synth for home studio purposes. And with usb uploading of midi files to the SD card. And midi controlled Hi-Z guitar input to the XR385 board. And midi controlled effect loop switching. And of course a simple headphone amp. Line in and Line out. And... And.. And... (Midibox virus detected)

Edited September 17, 2012 by Martijn

[sparx]

is the double NAND necessary

I don't know for sure but would have thought so. Looking at other designs, they all use a 7400 in this part of the circuit and most use the LS version.

What I can tell you is that one device I wish to add to this setup won't work with the Core MIDI output, but does with the NAND output, makes sense to use something that will work rather than something that may work?

S

[EsotericLabs]

is the double NAND necessary

I don't know for sure but would have thought so. Looking at other designs, they all use a 7400 in this part of the circuit and most use the LS version.

What I can tell you is that one device I wish to add to this setup won't work with the Core MIDI output, but does with the NAND output, makes sense to use something that will work rather than something that may work?

S

Thanks for sharing your experience. I'll test when the card arrives and indeed: why not put some 7400 IC in there.

[EsotericLabs]

Hello,

May I ask for debugging hints? I have a NEX XR385 card; the DB60XG clone connected to my LPC 17 core. I think its properly set up and connected (at least I'm out of debugging ideas), but: No Sound...

All PSU pins on the card show proper voltages; the card's midi is connected to j4b.Sc. first directly, then through two stages of a 74LS00 (double NAND) as in most schematics for waveblaster breakout boxes, with a 1k2 pullup to +5V on the TTL signal input (elector; GM Voice by Sparx; Mikes, Wave SA). Line outs are fed directly into crappy but functional PC speakers. Pin 4 of the soundcard (midi in) with the 74LS00 buffer measures 1.43V, J4B.SC on the core measures 2.15V. I interpreted this as some average over a signal of zero's and ones (+5V) as i don't have a scope. Reset (pin 26) is properly pulled up to +5V with 10k and has a 10uF elco to GND.

Got the card from Ebay, one SMD elco fell off and i replaced it with a regular one. c33 and c34 make the speakers hum when touched left resp right.

My firmware is basicly tutorial #001 forwarding midi - with all input going to UART3 - thats midi 4 out aka j4b right? #define MIOS32_UART_NUM 4 is present in mios32_config.h but no further initialization in App_init. I added debug messeage to tell of incoming midi in the mios terminal - this works fine. But no sound.. I added a GM reset to the App_Init and a "set master volume to 127" thru sysex. But no sound...

I feel I'm stuck, I would appreciate your debugging hints & directions to look into very much. Or might the soundcard itself be faulty?