TK.

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. 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. 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.

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.

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.

Yes, 303 View is only available for the 16x16 configuration, not only because there is no free selection button, but also because the special keyboard handling which requires 16 buttons in a row. It's more or less an artifact - a disabled note will be handled like key 0 I don't think that it's required to mask it out, because it's very unlikely that somebody will play notes with such low key numbers. Best Regards, Thorsten.

Confirmed that this is an imperfection which will be (hopefully) fixed sooner or later. Best Regards, Thorsten.

They won't be deleted, which means that they could still be taken over if enough tracks are selected during a PASTE operation. Best Regards, Thorsten.

You are right, I haven't considered this (relatively new) feature which was actually implemented for another purpose. It should work! :) Best Regards, Thorsten.

It's still on the wishlist, but not implemented. See also: (you are the only guy who requested this yet) Could you please check if this also happens if your Akai device is clocked from a PC via USB MIDI? Best Regards, Thorsten.

yes Best Regards, Thorsten.

Yes, 16x16 matrices can be handled in C w/o problems, especially because the actual DOUT transfers are handled by MIOS8 in background with an optimized assembly based routine. The mechanism is always the same: SR_Service_Prepare() will be called before the SRIO scan (each mS) In this function, increment a counter variable on each cycle, reset to 0 once it reaches 16 Transfer the new pattern (which corresponds to the counter and is ideally stored in an array) via MIOS_DOUT_SRSet Please note: a 16x16 LED matrix means that the 16 LED rows will only be visible for 6.25% of the time - the brightness won't be optimal! It's better to implement two 8x16 matrices instead (counter from 0..7) Best Regards, Thorsten.

I agree with the ALT button behaviour change, although it will lead to the minor issue that BLM Emulation users who use a mouse to activate the buttons won't be able to access ALT+<function-key> anymore, since a mouse can only select a single button. However, sooner or later I will add a special key for this (like I did for the SHIFT button, which can be activated with the space key) Drum instrument selection is now supported in Grid mode. http://www.ucapps.de/mios32/midibox_seq_v4_087_pre3.zip Best Regards, Thorsten.

Here a new beta version with enhanced BLM support as discussed above + the ALL button fix: http://www.ucapps.de/mios32/midibox_seq_v4_087_pre2.zip I also created a new version of the BLM emulation which shows the new layout (with ALT and UpperTrk button): http://www.ucapps.de/midibox_seq_manual_blm.html Best Regards, Thorsten.

Of course, it's possible to create a LED matrix with a PIC18F in C. Unfortunately there is no simple example available, only complex examples like this one: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_mm%2F&# (see SR_Service_Prepare() function in src/main.c and the appr. code in src/mm_vpot.c) Best Regards, Thorsten.

Well, it seems that the SysEx communication is working. It's normal that no dumps are received for a bank (because no BankStick is connected) or patches (because your MIDIbox isn't configured for patch mode). If the MIDIbox editor doesn't work at your side, unfortunately I can't change this, because this is a quite old software which I haven't implemented by myself. There is an alternative possibility: you could generate a .syx file with the mk_syx.pl script which is part of the installation package (-> see mk_syx/README.txt) It requires a perl installation on your PC, available here: http://aspn.activestate.com/ASPN/Downloads/ActivePerl/index/ The .syx file can then be uploaded with MIOS Studio, you've already proven that this communication is working, so that I'm sure that this will lead to a successful re-configuration which is just a little bit less comfortable than the GUI :) Best Regards, Thorsten.

This makes sense, I added the request to the wish list. Best Regards, Thorsten.

Good ideas, added to wishlist, I prefer option 1 Best Regards, Thorsten.

Request 1 and 2 can be easily implemented, for Request 3 I've doubts that people will really spend the time to organize the SYSEX directory this way - I will wait for more people who like this approach (or who have alternative ideas). Best Regards, Thorsten.