TK.

In song mode the reference measure for synching pattern changes is always 16 * 16th notes, so it works like intended. In newer MBSEQ V3 releases, the number of "reference steps" can be selected between 1..256, but this won't cover your usecase, as this is a global setting, which will be used for all pattern changes. To be honest: I don't know how to solve your request! There are different step lengths possible for all 16 tracks, how should the firmware determine the intended pattern length without limiting existing possibilities? (e.g. playing 8 step tracks 2 times before changing to the next pattern?) Best Regards, Thorsten.

Shipped today: kynsi Flexinoodle QuPe grnsky lucem Yogi gnups JW LinkwitzRiley ultra Oman Jan75 Jurbo StormB Will be shipped once I got the money: nebula curve Frank mbreges midigor agxaudio No response yet - your order will be cancled in ca. 1 week if I don't get a reply to my PM until then. If you already know, that you don't need the chips/PCB, please write me now dynamona this SirVish pomics Roverbox Edis trainspotter zgba matyt deno31254 Zzzz... (please wake up) emju Edis intellijel woluf Freidieb Serge_D Harley Godzisz Snyderman 3amsleep ballpein Best Regards, Thorsten.

The software sees 4 events, but due to the detent it should only increment one time for 4 transitions. There is of course an optional "progression" algorithm in MIOS, which increments with higher values if the encoder is turned faster. But for slow moves it has to increment a single step per detent, otherwise you would miss some values when finetuning a parameter. Which are interpreted as a single Inc/Dec if a detented encoder type is selected in your MIOS setup - yes. Yes - which is optionally done if the encoder is turned faster (depending on the "speed parameter" you could even see more inc/decs No, the advantage is, that with a non-detented encoders you can stop turning "in the middle" of 4 Inc/Dec events, which are normaly required for a single "click". Accordingly, you will get a higher resolution if the encoder is turned slowly. Another advantage is, that you will get a less steppy feel if the encoder is turned fast. On the other hand: detents are great if you want to control low-resolution values, because they give you a more precisely feel. Therefore I recomment detented encoders for MBSEQ (where you want to enter note values precisely), and for the datawheel of MBSID (not for the remaining encoders, as you want to tweak CutOff (as an example) quickly). It makes sense to try a detented encoder first - and if you don't like the feel (and the noise when turning the encoder), just remove the detents... or buy some non-detented encoders later. Best Regards, Thorsten.

We reached beta9 state: Moved icon and menu items for MIDI Device Routing Implemented XML save/restore feature for all elements of MIOS Studio on closing/reopenning. Workspace configurations can also be saved and restored via File menu MIDI Filter definitions can also be saved/restored via XML Changed MIDI Device Manager handling of physical MIDI Devices. Fixes problems with mmj re-adding the same devices when rescanning, and virmidi listing multiple devices for each port. Thanks again to Adam! Best Regards, Thorsten.

The internal IO pin output drivers of the PIC are already limited at 25 mA, so that the 100 ohm resistor doesn't make a big difference. I think, that an additional protection isn't required, but if somebody experienced problems with shortened IOs, please let me know. Best Regards, Thorsten.

I guess that you assumed that removing the detent would already increase the resolution. This of course won't help - there are also some software changes required. Maybe this illustration helps to understand the approach: If you remove the mechanical detent, you will remove the "click" shown in these waveforms, so that all transitions of the quadrature code can be used to determine, if the encoder is turned clockwise or anti-clockwise. Considered, that the SW scans the encoder fast enough, it is possible to quadruple the resolution of a "DETENTED2" type encoder Best Regards, Thorsten.

MIOS Studio tries to upload code, but it periodically gets an upload request, which means, that the bootloader doesn't receive the first code block and endless requests for new data. There seems to be an issue with the MIDI In port. I would propose to check TEST_IN1..TEST_IN7 and TEST_INOUT1 of the troubleshooting guide and to post the results here to give us an impression about what is already working. The same effect (upload requests, but receiving the code block fails) happens with a rare number of MIDI interfaces which are on the Blacklist, but I guess that this shouldn't be an issue with yours (TEST_INOUT1 helps to detect interfaces which don't transfer SysEx streams correctly). Best Regards, Thorsten.

Actually there are two options, which are documented here, search for "ABW" Either you disable the ABW (ADSR Bug Workaround) flag in the configuration menu so that drum sounds will be played immediately. But this can lead to envelope hickups or even more random timings (only if AD and R = 0 the gate will open immediately, in all other cases they have a random lag between 0..25 mS) Or you enable it, which has the advantage of completely working ADSRs and a defined delay of 30 mS, which can be easily compensated in a DAW - even for live sessions (e.g. in Logic Audio, all tracks which don't use the ABW are routed to a bus which inserts a +30 mS sample delay). Best Regards, Thorsten.

BL 1X20G 2,54 Best Regards, Thorsten.

It takes longer for me to find this out, than for you to update the firmware! Best Regards, Thorsten.

I'm not sure what you mean with "bd1"... VAs is only available for multi and drum engine patches to assign the voice to a specific oscillator, to a specific SID (L/R) or to use auto allocation (default). Usually we only want to use a single oscillator per drum sound. We have two SID chips per core, accordingly 2*3 oscillators. The two SID audio outputs have to be "merged" with a mixer (or in your DAW), e.g. by enabling a Mono function. However, this doesn't explain why you hear it louder, which implies, that you can hear the same sound on the other audio channel, which would be wrong. Maybe a crosstalk issue? Or do you refer to a lead patch which plays a stereo sound? Best Regards, Thorsten.

Thanks Stuart - yes, thats the concept. In MBSEQ V4, there are some optional "button behaviour" flags: // Toggle behaviour of various buttons // 0: active mode so long button pressed // 1: pressing button toggles the mode #define DEFAULT_BEHAVIOUR_BUTTON_FAST 1 #define DEFAULT_BEHAVIOUR_BUTTON_ALL 1 #define DEFAULT_BEHAVIOUR_BUTTON_SOLO 1 #define DEFAULT_BEHAVIOUR_BUTTON_METRON 1 #define DEFAULT_BEHAVIOUR_BUTTON_SCRUB 0 #define DEFAULT_BEHAVIOUR_BUTTON_MENU 0 #define DEFAULT_BEHAVIOUR_BUTTON_STEPVIEW 0 #define DEFAULT_BEHAVIOUR_BUTTON_TRG_LAYER 0 #define DEFAULT_BEHAVIOUR_BUTTON_PAR_LAYER 0 [/code] With DEFAULT_BEHAVIOUR_BUTTON_MENU set to 1 you will get your recommented behaviour. Initially I only added this for the emulation, as it isn't possible to click&hold this button with the mouse, while moving to a GP button to click it as well (typical issue when using a mouse, and the reason why we prefer real hardware ;)) With the real frontpanel, mode 0 is much better, as it allows you to browse through the menu pages quickly. E.g., Press & Hold the MENU button, press GP button 1, 2, 3, ... --- you will select the appr. menu so long MENU is pressed. This allows you to find a menu page if you don't know the GP button number anymore (or if your frontpanel has no additional menu page labels below the GP buttons). With your proposed behaviour, this quick browsing through the pages wouldn't be possible anymore. You would have to click on the MENU button again and again to change the page, which is cumbersome and time consuming. Another hint: by pressing the EXIT button you will get a menu which allows to access *all* pages, even the hidden ones (e.g. Formatting BankSticks) Best Regards, Thorsten. P.S.: it isn't possible to add the same behaviour flag to MBSEQ V3, since the firmware would have to be overworked at many places. But I guess that you will like the current implementation anyhow - sooner or later ;)

You could link it at least via MIDI ;) The MIOS8 based version already works standalone - a MIDI device can be connected directly w/o the need for a PC. But yes - I'm planning a MIOS32 version as well. It's a bit exorbitant to use a 32bit core for a device which already works perfectly with the PIC, but we will get the advantage of native USB MIDI and native OSC support via Ethernet w/o the need for OS dependent proxies. Do you know the difference between the old and the new Stribe1 kit? No - as this is already provided by the PIC based firmware. And as you can read, we are even going higher :) Best Regards, Thorsten.

ok Best Regards, Thorsten.

Shipped today: metaBit Juel Deimos levtermen koppi chinchiu diablojoy alessiol Bosone Just Phil dukankallemegper xarolium mgebauer khkremer Erglis ozatomic nILS rosch All2u Napiks cyberheater nykwil humbucker Peter888 xpa theo3 Gioxannes discostu julienvoirin j00lz Will be shipped once I got the money: kynsi curve mbreges lucem gnups JW midigor LinkwitzRiley ultra Jan75 Jurbo No response yet - your order will be cancled in ca. 2 weeks if I don't get a reply to my PM until then. If you already know, that you don't need the chips/PCB, please write me now dynamona this nebula SirVish pomics Roverbox Edis trainspotter zgba matyt Flexinoodle Frank deno31254 QuPe Zzzz… emju Edis intellijel woluf Freidieb Serge_D grnsky Yogi Harley Godzisz agxaudio Snyderman Oman 3amsleep ballpein StormB Best Regards, Thorsten.

This was the initial behaviour of the OSC button in early MBSID V1 releases, but I found the current solution much better. Since nobody complained about this change, I removed the option in MBSID V2 completely... However, it shouldn't be too much effort to add it again, and make it selectable in the setup_* file: ;; if 0: OSC button selects also combined modes (7 states, combined OSCs) ;; if 1: OSC button selects only one of three OSCs (faster handling) #define DEFAULT_OSC_BUTTON_BEHAVIOUR 1 [/code] [s]So, once the next release is available, you will have to set this value to 0 for your customized firmware (I guess, that sooner or later you will set it back to 1...)[/s] No compile switch available - the proposed selection logic "1--, -2-, --3, 123" now the one and only default Best Regards, Thorsten.

The code isn't compatible (e.g. due to different function names and different variable types), but the concept is the same for PIC based MIOS. Sure - use a 16bit variable (unsigned short) as a counter. Increment it on each SRIO_ServicePrepare() invocation (each mS), and set it back to 0 once it reaches 1000 (== 1 second). Now you could apply an inversion mask to each DOUT bit which should flash whenever the counter is > 500, this gives you a 1:1 flash ratio. Best Regards, Thorsten.

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fmidifile%2F http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fsequencer%2Fmid_player_sd%2F Best Regards, Thorsten.

This is a C based example, which demonstrates the usage of the assembly based BLM driver for MIOS8: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fbutton_duoled_matrix%2F This C based module (which is only provided for MIOS32, but could also be ported to MIOS) is an example how to handle a 8x8 button/LED matrix: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fblm8x8%2F if you remove all functions which are related to button handling, you will get the code for which you asked for (or the other way around: BLM8X8_PrepareCol() is the only relevant function for your usecase) Definitely yes, as the DOUT register handling itself is handled by MIOS, and it's already speed optimized so that you don't need to take care about the low level stuff. Just hook the code which periodically changes the DOUT values into SRIO_ServicePrepare() - this function is called each mS before MIOS updates the DOUT registers. No, because a really satisfying PWM requires a much higher update frequency - details: see this article: http://www.midibox.org/forum/index.php/topic,10915.0.html Meanwhile I developed a simple way to generate PWM, an example code can be found under http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fbootloader%2Fmain.c (MIOS32 only, search for PWM) But it only works if the LED is directly connected to an IO pin. It won't work for LEDs connected to the SRIO chain due to the slower update frequency (1kHz instead of 10 kHz), and it especially won't work for multiplexed LEDs, since it reduces the update frequency (e.g. 8x8 matrix: 125 Hz instead of 1kHz) Best Regards, Thorsten.

Hint for programmers only: you could write an application which sends the pot values via MBNet (CAN interface) to MBSID. Advantage: very generic approach, highest speed (CAN messages are transfered with 2 MBit/s), no MIDI merger required, no additional latency caused by a MIDI merger connected between your MIDI keyboard/PC and MBSID So long you don't ask me "how can I enable this in the firmware" or "could you please write me the complete application", I can give you the required details. You can reuse some parts of MBSID, but in this case it will be assembler-only. It could also be realized with the new MBHP_CORE_STM32 module, in this case a driver for MBNet written in C and a pot handler which can scan up to 128 analog inputs is already available. You only need to write the communication handler (pot in -> MBNet out) Best Regards, Thorsten.

I will add a CS_MENU_BUTTON_Arp into the next release, which will allow you to enable/disable all 6 arpeggiators of the selected SID (it was planned anyhow) You will be able to map this function to a free DIN pin in your setup_*.asm file. I guess that a LED function would be useful as well? I don't think that it is really required to map this to an analog input (waste of resources), because you only want to switch between On and Off... or did I overlook something? Best Regards, Thorsten.

...and compare it with the Blacklist Most low-cost interfaces provided by Thomann are working unreliable. Today you can buy an USB based Multi Purpose card reader for less than 5 EUR, but usable MIDI interfaces are still so expensive like 10 years before. However, seems that this is still a field where you can save money with DIY :) Best Regards, Thorsten.

Ploytec was well prepared - I already got the chips. PMs are sent out Note that currently there are at least 20 spare parts - first come, first serve! Best Regards, Thorsten.

yes, it seems that volume CC is not mapped!!! But all the remaining CCs should work - can you confirm this??? Best Regards, Thorsten.

Yes, it should also work on a PIC18F4685, although I never tried it. A 24LC512 doesn't give you any advantage, because only the lower 32k range is used. Best Regards, Thorsten.