TK.
-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
It's maybe better to start with a simple example, not the one from the tutorial.
Chords are already useful w/o the force-to-scale function (the tutorial is an advanced example).
The chords can not only be transposed from an external keyboard or from a loopback track, but also with the static track transpose function (press MENU->Transpose)
This is sufficient for most ambient and Berlin style tunes (especially when Minor chords are played ;-)
Originally chords were only intended as some kind of quick composing help. For more sophisticated chord progressions it's better to use the recording functions - especially the recently introduced EDIT Recording function simplified this a lot!
Best Regards, Thorsten.
-
Unter diesen Umstaenden sollte das eigentlich nicht passieren.
Arbeitest Du eigentlich unter MacOS? Da gibt es ja die MIDI Monitor App, die eine Spy Funktion anbietet, mit der man die MIDI-Meldungen beobachten kann, die an das MBHP_MF_NG Modul gesendet werden: http://www.snoize.com/MIDIMonitor/
Fuer mich waere es hilfreich zu wissen, ob die Meldung von der DAW gesendet, aber nicht bearbeitet wurde (dann liegt das Problem auf meiner Seite und wir muessen einen Weg finden, wie ich das bei mir reproduzieren kann) --- oder ob die DAW die Meldung gar nicht erst rausschickt (dann ist die DAW daran schuld).
Gruss, Thorsten.
-
I understand the problem, but I can't provide a solution (yet)
Best Regards, Thorsten.
-
Ok, I will check this by myself this weekend.
I remember that I upgraded the USB driver some weeks ago to get the USB Host functionality - there might be corner cases that I haven't tested yet.
Best Regards, Thorsten.
-
I believe that this is related to an electrical problem.
Power might be the reason... how is the MIDIbox supplied? Via USB? I hope that you are using an USB hub with external PSU!
Or if it's related to a short in the LCD cables or bad soldering work around LCD pins and J15A/B pins.
Let's decode the displayed messages by the expected messages.
E.g. instead of "MIDIbox" we can read "MMLMbo|"
The hex code of MIDIbox is: 4d 49 44 49 62 6f 7c
And the hex code of the wrong message is: 4d 4d 4c 4d 62 6f 78
This looks like a problem between the D3 and D2 wire.
Best Regards, Thorsten.
-
It's always a good idea to try out one of the prebuilt binaries which can be downloaded from http://www.ucapps.de/mios32_download.html such as MBSEQ, MBNG, MIDIO128.
These apps are some kind of reference, because they have been tested at my side (with different operating systems and with different computers) and they are used by multiple people who haven't reported such problems yet.
All these applications output debugging messages after power-on (-> this is no exotic case)
That's actually also the reason why I think that the problem is located somewhere in your application, and not in MIOS32 itself.
Best Regards, Thorsten.
-
Hallo Stephan,
passiert das, wenn sich alle Fader gleichzeitig bewegen?
Dann ist das Netzteil zu schwach, es muss mind. 1A liefern.
Gruss, Thorsten.
-
Hi Wouter,
it looks like an issue with the cables between the LCDs and J15A/B of the core module.
What happens when you open the case, move the cables a little bit and reboot the device?
Best Regards, Thorsten.
-
That's good, because I will be on a (business) trip as well ;)
Best Regards, Thorsten.
-
It's the normal behaviour, because there is no read-back path from the OLEDs to the core.
CLCDs have a bidirectional interface which allows to read the status.
Means: MIOS can only write to the OLED and assume that they are available due to the simplified SPI based interface.
@FantomXR: your problem is different from that, it isn't the same.
Best Regards, Thorsten.
-
Just ask NI about the communication protocol - but it might be that they want to keep it secret.
Best Regards, Thorsten.
-
but it shouldn't block on a high-priority thread like that. (MIDI receiving, MBNG event handling
Of course, and this is the reason why I added a timeout loop into MIOS32_USB_MIDI_PackageSend() some years ago, which works reliable.
I spent an immense (!) effort to reverse-engineer the issue which users only noticed under Windows so far.
I used several methods (such as trace points in MIOS32, USB sniffer, different implementation methods, etc) to get more informations about the issue.
Believe me (or not) but I think that the problem is at the OS side.
It's new to me that it also exists under Linux, you are the first guy who reports this.
Best Regards, Thorsten.
-
Please note that this MIDIbox SID V2 can be easily migrated to a MIDIbox SEQ V4 as explained here: http://www.ucapps.de/midibox_seq_manual_up.html :)
Best Regards, Thorsten.
-
Am I understanding the current implementation correctly? When the SEQ is playing, every time it hits a step, it runs SEQ_LAYER_GetEvents(). When the current layer is a chord layer, it hits the chord CASE clause, and runs SEQ_CHORD_NoteGet() four times to translate the chord letter (A-P or a-p) into notes. This translation occurs every time a step is played (in other words, the chords are not stored as notes, they're stored by name - as the equivalent of "A-P..." - and translated into notes when played.)
Yes... but they are stored by encoded value.
Each step in the parameter layers provides a 8bit value. The Chord number and octave is decoded into this value.
To implement this i-ii-iii-iv... proposal, a "case SEQ_PAR_Type_numChord" clause would have to be added to SEQ_LAYER_GetEvents(). If that clause ran a translator function that required similar processing power to running the current SEQ_CHORD_NoteGet() function four times, that would be efficient enough for the SEQ to maintain timing?SEQ_LAYER doesn't need a table reference for the number of notes.
It's sufficient when SEQ_CHORD_NoteGet returns a value < 0 if no additional notes should be played.
See also inline source documentation:
///////////////////////////////////////////////////////////////////////////// // This function returns the transpose value of a chord with the given // key number (0-3) // IN: key number (0-3) // chord number (bit 4:0) and octave transpose value (7:5) // returns note number if >= 0 // returns < 0 if no note defined for the given key ///////////////////////////////////////////////////////////////////////////// s32 SEQ_CHORD_NoteGet(u8 key_num, u8 chord)
(btw: just noticed that the documentation contained outdated informations about the encoding, I just fixed this in the source code and uploaded to the repository)
If you are planning to create chords with more than 4 notes, just increase the number in the SEQ_LAYER based "polling loop", and ensure that SEQ_CHORD_NoteGet() can handle more than 4 notes.
...and when I'm in SEQ_LAYER_GetEvents(), seq_core_global_scale_root and seq_core_global_scale would be the right place to look to find the currently selected scale and root? Or would I have to call SEQ_CORE_FTS_GetScaleAndRoot() to get the current selections?SEQ_CORE_FTS_GetScaleAndRoot() is the right API, please use this one.
You could just patch your experimental code into the existing framework, once we are happy with the implementation I would enhance the infrastructure so that a second chord type is supported properly (many small changes at many places have to be done, but I can do this quickly once it's clear that the alternative handling is acceptable).
Best Regards, Thorsten.
-
Are you working under Windows, and does the application enable more than 1 USB port?
Then this is a known (Windows related) problem, and MIOS Studio has a workaround to overcome this (it sends a lot of dummy messages to the core until it unlocks the communication).
Workaround: enable the "single_usb" option with the bootloader update app, and power-cycle the core so that Windows takes over this single port configuration.
Best Regards, Thorsten.
-
Building a new coreboard won't solve this problem.
Just to check some basic thinks, please have a look into the schematic: http://www.ucapps.de/mbhp/mbhp_dinx4.pdf
Are you can see, the upper row counts from D7 to D4, and the lower row counts from D0 to D3 (reversed order).
Did you consider this?
This doesn't explain why you see a different order for the first SR, but I've the impression that you misinterpret something (which is hard to predict remotely with the given informations)
Best Regards, Thorsten.
-
It would work with a common C flow (e.g. on a MIOS32 core), but it doesn't work with MIOS8 in conjunction with the quick&dirty SDCC adaption, because it doesn't take care about variable preloading and initializes all variables (which are not declared as a const) with 0
So, you are on the right track, there is no cleaner way with the MIOS8/SDCC combo.
Best Regards, Thorsten.
-
D0=Button=Button#12, D1=Button#11, D2=Button#10, D3=Button#9
So, it behaves like if D0..D3 are mirrored?
Because my expectation is that D0=Button#9, D1=Button#10, D2=Button#11, D3=Button#12
You also mentioned that you tested this with MIDIO128.
Does it mean, that MIDIO128 shows the same mirroring?
Best Regards, Thorsten.
-
I come to very good results with the current chord mode strategy (even w/o force-to-scale), but maybe only because I think different ;)
E.g. I find it important that also single notes can be triggered, not only a combination of notes.
The enumeration (A, B, C) isn't a big problem if you learn them, the full name will be displayed at the right upper corner.
On the other hand it isn't a big deal to add an alternative chord mode which follows a different strategy, but I've to warn you that it also needs to be efficient (e.g. searching for the next note in the scale would result into a iteration which consumes a lot of processing time - too much to guarantee stable sequencer timings).
So, would be nice if you could elaborate a bit further how an efficient note selection could look like, and then I could give you feedback if it is feasible with the given timing constraints.
Best Regards, Thorsten.
-
One thing to mention is that I've always used 10k resistor packs for R33, the LCD line pullups, instead of the listed 1k
This is the problem.
Some time ago somebody else reported the same problem in this forum with the STM32F4 board (can't find the thread) and it turned out that this was because he used 10k pull-up resistors.
Yes, the STM32 output voltage is lower.
Best Regards, Thorsten.
-
This doesn't really surprise me:
120.0 BPM = one MIDI clock tick each 20.83 mS
120.4 BPM = one MIDI clock tick each 20.76 mS
So, you notice a jitter of about 69 uS - is this really serious? ;-)
However, note that the displayed BPM is a mean value over multiple samples, and therefore dramatic peaks could be filtered out (there is no in-built statistical analysis over the clock quality...)
Do you notice an audible difference?
Some time ago I wrote a "clock accuracy tester" for MIOS32.
I haven't checked if it also works with USB MIDI host mode, but it's maybe worth a try: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fbenchmarks%2Fclock_accuracy_tester%2F
Here some typical measurement results (min/max/average delay): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fbenchmarks%2Fclock_accuracy_tester%2FREADME.txt
Best Regards, Thorsten.
-
Read mode is used before each write operation to poll the busy flag. Since the LCD is clocked asynchronously and execution times can vary depending on the ambient conditions (e.g. supply voltage and temperature), this is required to ensure that the write data can be processed.
I'm a bit unsure if it would be possible to poll only the busy flag of a single LCD, and if the second LCD will always behave similar (need the same delays). It's something that has to be tried out, with some luck it will work.
But then you would still need to solve the read data collision issue. A transmission gate based buffer could work if switching between opened and closed state is high enough, and the higher impedance doesn't influence the data lines - I've no experiences on this topic.
However, switching between the two LCDs is easy: actually you only need to route the E signal to one LCD, and set E to 0 of the other LCD.
You could use a common toggle switch for this purpose, just add 10k pull-down resistors to the E inputs to ensure that they are logic-0 when the switch doesn't route the E signal to the input.
There might even be a solution to switch "automatically" once D-Sub connector is plugged into the socket so that no switch is required by using logic gates instead of a mechanical switch.
Note that you need to reboot the device in order to initialize the LCD once it has been selected with the switch.
Best Regards, Thorsten.
-
Hi,
welcome on board! :)
The backlight of a LCD isn't connected to the core, but via T1 (a current source) to the PSU. It's possible to supply multiple backlights at once, and with two LCDs the power consumption should still be less than 500 mA (the 7805 works at up to 1A if a heat sink is mounted).
But it will be problematic to drive two LCDs at once because of the RW line which selects read mode with RW=1.
In read mode, both LCDs would drive the data lines (D0..D7) and this results into a short circuit.
The second core only prints a dummy message, it can't display the same informations like the master core.
Currently I don't see a solution for your intentions :-/
Best Regards, Thorsten.
-
Yes, this would be interesting as well.
I'm asking for any comparison which helps to identify if either the USB MIDI Host of MBSEQ or the USB MIDI Device of your Akai device causes the bad timing.
Best Regards, Thorsten.
Waiting for response from MIOS Studio?
in Testing/Troubleshooting
Posted
I hope that I found & fixed the issue (-> update your repository)
It's related to a bug in the STM32F4 driver as described here: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fYet%20another%20STM32F1057%20USB%20OTG%20driver%20issue%20%28VCP%20device%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=2734
I was only able to reproduce it with my 10 years old Linux laptop, and even there it didn't always happen, but only sporadically.
Therefore I hope that this helps at your side - otherwise I've to give you some hints how to continue debugging (requires a scope to monitor the IRQs)
Best Regards, Thorsten.