TK.

Yes, a separate topic makes sense for all conversations which belong to John's project, so that it's easier for interested readers (who want to build something similar) to follow. Any proposal for the subject? Best Regards, Thorsten.

Ok, sounds feasible! :) I will implement this in one of the next weekends. Best Regards, Thorsten.

The warnings can be ignored, the app is ready for upload :) Sidenote: I got the differential line drivers two days ago, and will test them with the AOUT_NG (for CV out) and DOUT (for gates/triggers/switches) modules next weekend. Best Regards, Thorsten.

Yes, it's on my TODO list. Only problem is that the complete SysEx stream needs to be buffered in RAM before it's stored on SD Card. Accordingly, the used core module (LPC17 or STM32F4) will limit the max size. E.g. with STM32F4 it would be possible to handle 64k dumps easily, but for LPC17 I fear that only 4..8k can be buffered. How long is the SysEx dump of your drum machine? Best Regards, Thorsten.

I can't help you on potential issues with jOrgan, Linux or your special hardware circuitry. However, hopefully a hint which helps: I don't know what you mean with "gc", but I guess that you want to say, that strange (uncontrollable) things happen when many outputs are changed at once, right? Does this also happen if you remove parts of the hardware? E.g. especially to 3) - do these SAMS also flutter if all other SAMS are disconnected? And how long are the cables between the Core, DIN and DOUT modules? They should be as short as possible! Best Regards, Thorsten.

As long as the oscillators are running at the same (or dividable) frequency, they will stay in phase. Once you change the finetune value, they should get out of phase again. It's the same phase that you find in the OSC menu page of the CS. There is only a single phase parameter for all 3 oscillators. Best Regards, Thorsten.

Well, the best way would to use a MIDIbox CV V2, since it provides special stereo effects in the modulation matrix. See also my 2xSSM2044 experiments :) -> yes! no problem, the OP Amps of the AOUT module will require less than 10 mA What is the CV control range? Anyhow, just start with these values, they are fine for 0V..11V Solder R_x and R_y in a way that you could easily remove them if you need different values. with MBCV2 you will get up to 64 additional gate/trigger/switch outputs in the DOUT SR chain. You could use some of the outputs for this purpose. V2 is the better choice. Best Regards, Thorsten.

Yes, it's always better to accept dropped events than running into the danger of an infinite loop. Working with the reduced resources of an embedded system means to accept potential failures which are almost everywhere. The challenge is to design the software in a way so that a common user will never notice this ;-) Best Regards, Thorsten.

No special installation is required. Assumed that the standard libraries & tool installations used in Puppy Linux are compatible to most other Linux derivatives, you can simply unpack the package with: tar xfvz MIOS_Studio_2_4_6.tar.gz and then execute the unpackaged binary with: ./MIOS_Studio Best Regards, Thorsten.

Yes, because the Background task has the lowest priority. Only tasks with the same (or higher) priority would be executed in the 1 mS window anymore. See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F006_rtos_tasks%2FREADME.txt The allowed priority range is between 0 and 5, where 0 is the lowest priority (equal to the APP_Background task), and 5 the highest priority. Tasks with higher priority can always interrupt tasks with lower priority. Accordingly, tasks with lower priority will only run when no higher priority task is executed. If --- and this is the big advantage of a RTOS scheduler --- tasks at the same priority level are running for more than 1 mS (the system tick), the current task will be interrupted automatically and the next waiting task with the same priority is started. This is called preemption -> http://en.wikipedia.org/wiki/Preemption_(computing) You will love this feature, because it allows to run time consuming loops quasi-parallel without taking care for compute time sharing (as long as tasks are running at the same priority level). Best Regards, Thorsten.

In general, interrupts shouldn't be disabled by more than 10 uS. Use a different method if your code accesses shared resources, e.g. use portENTER_CRITICAL() / portEXIT_CRITICAL() or a mutex if only tasks access the resource. For UART based MIDI a received MIDI byte could get lost if interrupts are disabled for more than 600 uS For USB based MIDI the host will be blocked (but it will queue the messages) For transmitted MIDI streams the ringbuffer will collect data, but the size is limited. On the other hand, it can typically bridge ca. 20 mS... if your application really needs more time where the ringbuffer can't be emptied, then consider software changes, e.g. offload to tasks which are running with a priority less than 3 (MIDI is handled at priority 3) Best Regards, Thorsten.

Congratulations Pete, this time you replied 1 minute earlier than me! (because I compared some schematics in the internet... ;-) And I agree with you, that 47 Ohm is the best choice! (we would also have to consider the internal resistance of the TX pad, and of the MIDI cable...) However, I'm glad that we got this solved! :smile: The purpose of these resistors is to limit the current, especially if somebody plugs MIDI OUT into another MIDI OUT or THRU, or if the MIDI cable is broken (in worst case, the 5V resp. 3.3V supply voltage would be connected to ground), or if the cable has the wrong polarity. I remember that ca. 20..30 years ago (the time MIDI came up) some kind of crosslink cables with the same plugs were sometimes used for hifi systems, e.g. for tape-to-tape recording. If you would connect such a cable between two MIDI devices, you would drive the optocoupler at the other side in the wrong direction, and without current limiting it would heat it up. At the optocoupler site there is a polarity protection as well (the 1N4148 diode) - but if it doesn't exist in the MIDI device with a poorly designed MIDI IN circuit, there is a certain danger that the optocoupler will be fried. This is very hypothetical, but it's always a good idea to consider such safety measures at both sides! ;-) Meanwhile I also changed the MBHP_CORE_LPC17 schematic and the BOM: I'm now recommending 47 Ohm resistors for R21, R22, R26 and R27 - the reason for this measure is described in the list of LPC17 imperfections. I recommend you to do the same. E.g. I just checked how Mutable Instruments implemented the MIDI OUT. They are using a 100 Ohm resistor at the 3.3V pin, but no resistor at the Tx pin. For the Shruthi synth they are using a 220 Ohm resistor at the 5V pin, and again no resistor at the Tx pin. Hypothesis: if somebody would plug the MIDI OUT of a MIDI Pal into the MIDI OUT of a Shruthi (by fault), it would result into a short circuit between 5V and 3.3V, which is only limited by the internal resistors and protection diodes of the Tx pins. This isn't really so dangerous, but it's also not so nice... Such an issue is btw. another good reason, why it's better to configure the Tx pin in open drain mode instead of push-pull if the MCU allows this. Best Regards, Thorsten.

Thanks for the hint! It's fixed now Best Regards, Thorsten.

Wow! No information can be found about this board in the internet. It seems that it has been produced in the same year like Rev B (2010), but nether went into mass production (I guess for good reasons... due to the incompatible pinning). Please let us know about the comment from Embedded Artists Best Regards, Thorsten.

Before trying to level shift the Tx signal (which involves some soldering work and an additional IC, such as a 74HCT541), following experiments would be interesting. 1) connect your MIDI synthesizer to MIDI OUT1 - are you able to play notes? 2) connect your MIDI Pal between MIDI IN1 and OUT1 - does it show the outgoing MIDI data, and is MIDI loopback working? 3) and now the trick: bridge R21 (a 220 ohm resistor) with a small cable so that it doesn't limit the current draw anymore. Together with R22 (the second 220 ohm resistor which shouldn't be bridged (!) to prevent a short circuit between ground and 3.3V while plugging in the cable), this should result into a current draw of ca. 7.5 mA, which is still close to the MIDI spec, but might help in your case. Background: actually the MIDI spec says, that the current loop requires about 5 mA. Assumed that the MIDI Out has two 220 Ohm resistors in serial, and the MIDI IN of the target device has a single 220 Ohm resistor as well, this results into exactly 3.3V / 3*220 Ohm = 5 mA However, some interfaces might have a poorly designed MIDI IN circuit, so that this is not enough to drive the optocoupler. @Dugan: could you please also check if 3) solves the issue at your side? If this solves the issue, I will document the workaround at the MBHP_CORE_LPC17 page. Fortunately with the STM32F4 core it will be possible to use the Tx pin in Open Drain mode again, so that MIDI OUT can be supplied at 5V and therefore no adaption issues can be expected (due to a hardware imperfection in the LPC1769 chip this isn't possible). Best Regards, Thorsten.

Hi, actually there are more than 500 parameters, see also http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt Or have a look into the Editor: http://www.ucapps.de/midibox_sid_manual_ed.html yes Best Regards, Thorsten.

It can't be changed by the user without recompiling the application, therefore very unlikely. And LPC17 wouldn't be able to receive MIDI messages from your Roland UM1 if the baudrate would be wrong. I think that it it's neither a synchronization, nor any other software issue. It seems, that your Roland UM1 interface can't handle MIDI signals at 3.3V level correctly. There is a small number of MIDI devices where this is the case, they are designed for 5V signals, but LPC1769 (like many other modern microcontrollers) can only supply 3.3V. Therefore the next test: try another MIDI device. If it works, then we can start to think about workarounds for your Roland UM1 (e.g. usage of a level shifter). Best Regards, Thorsten.

Hi, MIOS32_SRIO will set a "changed" flag whenever a DIN pin has toggled during a scan. Even if the pin is toggled back to the original value, APP_DIN_NotifyToggle will still be called, but with the current value. In other words: it won't be called twice. If any edge is for interest, then you've to use the APP_SRIO_ServiceFinish() hook and detect pin changes from there (see also the various $MIOS32_PATH/modules/blm* examples) - but this is an interrupt. Time consuming operations (e.g. MIDI output) shouldn't be done from there. You would need to implement a queue mechanism if any pin change is really for interest. If you would describe your use case a little bit further, I could give you more concrete help how to solve the issues in your application... Best Regards, Thorsten.

Hi, are you sure that the SID chip itself is working? E.g. has it been tested on a C64? Best Regards, Thorsten.

I guess that the best way to handle this would be a software extension in MIDIbox NG instead of wasting AOUT pins. I won't have the time to plan and test such extensions in the next 2..3 weeks, but I will come back to this topic then. The most simple way would be to provide new AOUT channel targets for finetune and octave + semitone based transpose, right? See http://www.ucapps.de/midibox_ng_manual_ngc.html (search for nrpn_format) Currently only "Normal", "Signed" and "MSBOnly" are supported, I haven't seen a usecase for LSBOnly yet, but this could be easily added if you describe your use case Best Regards, Thorsten.

Hi Gerhard, the reason why I came to the idea that you are testing the MIDI OUT wrongly was simply because you haven't described how exactly you are testing the MIDI OUT port. It was the only conclusion at my side. Especially since you wrote "but MIDI out does not work, there is no data transmitted." I'm pretty sure that this is not related to a software issue, maybe only due to a configuration problem (like if you would assume, that USB transfers would be forwarded to a MIDI port w/o special app configuration) Ok, next experiment (unfortunately again you haven't described *all* details, e.g. which MIDI interface you are using to test the OUT port, therefore I hope that following test won't confuse you again - just trust my guidance... ;-) What happens if you loopback MIDI OUT1 to MIDI IN1, and configure the MIDI router the following way: set router 1 USB1 ALL OUT1 ALL set router 2 IN1 ALL USB1 ALL I expect, that every MIDI note that you are sending with the virtual keyboard will now be sent back by the core due to the MIDI loopback. Accordingly, the MIDI IN Monitor of MIOS Studio should show the same events like the MIDI OUT monitor. Best Regards, Thorsten.

Hi Gerhard, how do you test the MIDI OUT, resp. how are you generating the MIDI messages? By default (if no control element is connected), no data will be sent to the MIDI OUT ports. You could enable message forwarding from USB with following terminal command: set router 1 USB1 all OUT1 all Then play some keys on the virtual keyboard of MIOS Studio -> MIDI OUT1 should output MIDI note messages. Best Regards, Thorsten.

RXD = 5V: confirmed TXD = 0V: very strange, it should be ca. 3.3V when no MIDI data is sent It's especially strange that you measure 0V at both TXD pins (the same soldering error twice - very unlikely?) yes, just click on the "My Media" button (right after the smilie) Could you please check the voltage at the remaining two TX pins? MIDI OUT3: J5B.A7 (LPC1769 pin P0.2) MIDI OUT4: J4B.SD (LPC1769 pin P0.11) And: are you sure that the application is running? E.g. is the query in MIOS Studio working? Does it return "MIDIbox NG V1.xxx"? Best Regards, Thorsten.

The compiler can't cause such a difference, and as long as you are using the recommended one (mios32_toolchain), it's ensured that you've exactly the same setup like me. I wouldn't use other compiler versions, especially since they could generate code with a different timing behaviour which could cause failures. The access time mainly depends on the performance of your display, and KS0108 are known for their bad timings (therefore these displays are also not supported so well from my side anymore...). E.g. whenever a data byte is written into display RAM, the driver has to poll a busy flag, and the time it takes for your display to get unbusy depends on the KS0108 clock (which is generated internally), and also on the temperature, etc... GLCDs with modern controllers (such as DOGM, but also SSD1306 and SED1520) can take over the data immediately, so that no busy polling is required, and deterministic access times can be expected (which leads to a much better performance of course) And which time do you measure on a LPC1769? Best Regards, Thorsten.

God Gväll to Skandinavia, thanks for the nice words. Since remote debugging is always a challenge, I'm happy that you got this nice OLED working! :) Best Regards, Thorsten.