TK.

Hi Flynn, I remember that I purchased some FSRs from Conrad ca. 14 years ago. The website www.conrad.de tells me, that they are still available, but in the meantime the price has increased by factor 2.5 (!) Best Regards, Thorsten.

thank you Moebius! Best Regards, Thorsten. FAQMARKER

Hi Robin, yes, this is allowed. You only have to take care that all interconnections are asynchronous signals. This means, there is a certain propability that some signals are one SRIO update cycle (period: 1 mS) earlier sampled than the others. This is no issue so long each signal is handled seperately. But once you are combining signals to a bus (e.g. to transfer a "x"-bit information), you need an additional signals which says, that the bus value is valid. If this is the case, I can write down some additional notes on this topic, but I need to know, which informations you want to transfer exactly. Best Regards, Thorsten.

Hi Robin, I'm sure that learning C is a step into the right direction, regardless how long it will take. C isn't that complex, you will find a lot of features in the book which you will never use (like struct's or enumerations), maybe the first chapters will already describe all the stuff you need to know in order to realize your application in C :) Best Regards, Thorsten.

Two things regarding the AOUT matrix: an additional LED matrix won't be required, because the existing one will just get an alternative view, which can be selected with a special button combination. Just think about the fact, that I would never modify my own MBSID case anymore, therefore I can guarantee that each future feature will work with this control surface. And I cannot guarantee that I will ever implement features for additional control elements (additional encoders/buttons/LEDs) for other people... Another point is, that the CS controllable AOUT function (which should work more independent from the MBSID engine) won't be available for the PIC18F452 due to memory issues. This is an enhancement which is planned for MBSID V2 which will run on a PIC18F4620. The reason why I'm not able to start with this major version change is because of a hardware bug in this chip which affects the reliability of the MIDI interface. Therefore I'm (still) waiting for an update from Microchip - once available, I will start with the implementation of new major functions Best Regards, Thorsten.

Bei diesem Angebot wuerde ich auch nicht lange ueberlegen - die Preise fuer MIDI Interfaces waren noch wesentlich hoeher, als ich damals das MBHP_USB designed habe, doch in letzter Zeit sind die Preise so stark gefallen, dass sich Selbstbau nur noch fuer Freaks lohnt. Zumal der Windows XP Treiber nicht wirklich zufriedenstellend arbeitet, und Microsoft das MIDI-USB Protokoll ziemlich stiefmuetterlich behandelt Doch eine Warnung vor Emagic Produkten: hierbei handelt es sich wohl um einen Ausverkauft, Emagic supported die ehemaligen Hardwareprodukte nicht mehr, seit die Firma von Apple aufgekauft wurde. Ob das Interface dann auch noch mit der naechsten Windows Version zusammenarbeiten wird, steht offen. Ich persoenlich schiele schon seit ein paar Wochen auf ein ESI M8U - ein Bekannter hat es bereits gekauft und ist zufrieden damit, bei Gelegenheit moechte ich mal die Latenz und den Jitter ausmessen (siehe http://www.midibox.org/forum/index.php?topic=2342.0), wenn die Werte nicht schlechter als bei meinem MIDIsport 2x2 sind, schlage ich zu. Uebrigens: interessanterweise liefert das MBHP_USB die besten Werte bei den USB Interfaces, doch was bringt das schon, wenn der WinXP Treiber nicht Multiclient-Faehig ist :-/ Gruss, Thorsten.

...oder eine Sammelbestellung mit ein paar Englaendern organisieren :) Gruss, Thorsten.

Hi Robin, I fear that the whole MIDIO128 application confuses too much. In fact you don't need to write anything into a .ini file (resp. into the midio_presets.inc file) - such possibilities only exist for people who want to configure the software without touching the code. You are writing your own software, which only requires a small subset of the preprogrammed MIDIO128 features. Your application mainly relies on MIOS functions, and mainly exists of selfwritten code. All the MIDIO128 stuff is only unnecessary ballast which makes the whole thing more complex than it could be. I will give you a short example in the hope that it opens your eyes - it's written in C, and it requires the MIOS C wrapper (plus the tools which are listed under http://www.ucapps.de/mios_c.html) Just download the C skeleton (which can be found at the MIOS download site), and ensure that your core is running with MIOS V1.8 (absolutely required!) Open main.c, and put following code into the Init() function: void Init(void) __wparam { // initialize the shift registers MIOS_SRIO_NumberSet(16); // shiftregisters MIOS_SRIO_UpdateFrqSet(1); // mS } [/code] and following code into the DIN_NotifyToggle() function: [code] void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { // send Note C-1, C#1, D-1, ... with the keys assigned to DIN pins 0..60 if( pin >= 0 && pin <= 60 ) { // send note on if key pressed (pin value == 0) and note off if key not pressed (pin value != 0) MIOS_MIDI_TxBufferPut(pin_value ? 0x80 : 0x90); // note number can be calculated MIOS_MIDI_TxBufferPut(40 + pin_number); // 40 corresponds to C-1 // send velocity: 0x7f if note on, 0x00 if note off MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f); } } type "make" in the DOS shell and upload the new .hex file If you now want to send additional notes, then just replicate the three MIOS_MIDI_TxBufferPut lines, and modify the MIDI channel. For Channel #2, write 0x81 instead of 0x80, and 0x91 instead of 0x80 If the note values sent by the second core are different, then this only changes the calculations (xx + pin_number) I'm sure that we will also find C equivalents to the other functions you've already programmed (e.g. the SysEx send function) - you will notice that the code will be much better readable (and especially: changable) then assembly based code - and thats the reason why I strongly recomment you to use another programming language - your project is predestinated for C Best Regards, Thorsten.

Better to write: bsf PORTA, 0 nop bcf PORTA, 0 This only touches the first bit, and you don't need to take care about the other ones (bit operations are the big strength of microcontrollers) Best Regards, Thorsten.

I haven't read about such a problem yet, therefore it's unlikely that Ableton requires a periodically sent FE. Maybe Ableton users know more about such an issue? Best Regards, Thorsten.

According to the datasheet (http://www.standardproducts.philips.com/products/hef/pdf/hef4017b.pdf) much less than 200 mS (one instruction cycle of the PIC16F877). But take care: when you are generating the pulse by accessign the PORTx register via a read-modify-write instruction like bsf or bcf, you need to add one NOP between these instructions, otherwise the content will be corrupted. (PIC18F provides LATx registers, where this wait cycle is not required anymore) Best Regards, Thorsten.

Hi, -> see http://www.ucapps.de/midibox_seq_tutorial1.html :) Best Regards, Thorsten.

Hallo Benjamin, vielen Dank fuer das Lob (und natuerlich auch fuer die Kritik - die naechsten Layouts werden etwas relaxter partitioniert)! :) Zu 1) Ich persoenlich benoetige mittlerweile 3 EEPROMs: den ersten nehme ich fuer die 8580 Presets, den zweiten fuer die 6581 Presets, und den dritten fuer unveroeffentlichte Soundbasteleien. Darunter befinden sich mittlerweile soviele TB303 Sounds, dass ich wohl hierfuer einen vierten EEPROM spendieren werde. Zu 2) die Antwort wuerde mich auch interessieren! Bei Reichelt gibt es maximal das Format 500x100 Zu 3) so ein Blechgehaeuse wie beim Virus koennte man sich in einer Metallwerkstatt biegen lassen, die Seitenteile aus Holz gibt es beim Schreiner (oder bei Obi ;-) Zu 4) falls sich niemand in Deiner Naehe findet, kannst Du mir die PICs zuschicken. Gruss, Thorsten.

Hi Robin, I would suggest to put this feature into midio_din.inc, because this is the origin point where the MIDI event is generated, and all informations are available: you can check if a Note event should be sent, and you can send multiple MIDI events from there depending on the state of a certain DIN pin (just do this check with MIOS_DIN_PinGet) The advantage is, that this doesn't falsify the results of the very generic functions in midi_evnt.inc - you would still be able to send single notes independent from the state of the "coupling function" Last but not least this is the easiest solution - just add the code below MIDIO_DIN_Send Best Regards, Thorsten.

It seems that this is the same box which was sold in this auction for half of the price (!): http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&category=7797&item=7317281354&rd=1&ssPageName=WDVW And it also seems to be the same guy (look into the feedback history) - he lives in Hungary, not in Munich Best Regards, Thorsten.

I've finally managed to find a solution without compatibility problems: the keytracking value is stored within the same value which contains the SusKey flag I've also added the second interpolation - unfortunately it turned out that it doesn't help that much in the low-range of a 8580 filter, because a small change increases the cut-off so much, that it can be notified as a "stepiness effect". Sorry - no chance to improve this :-/ However, the new beta version is located here: http://www.ucapps.de/mios/midibox_sid_v1_7_303beta10.zip Additional changes: the MBHP_AOUT_LC outputs a 12bit filter value and a 4bit resonance value. 4bit is enough for the TB303 emulation which just increases the resonance on an accented note - finetuning can be done with an external trimmer (pot) Best Regards, Thorsten.

Yes, you have to specify the number of shift registers and the update frequency within Init(): void Init(void) __wparam { // initialize the shift registers MIOS_SRIO_NumberSet(16); // shiftregisters MIOS_SRIO_UpdateFrqSet(1); // mS } [/code] Best Regards, Thorsten.

Reg. the keytracking issue: maybe the best solution is to make MIDI sync a global parameter which is not stored in the patch. In addition, the wavetable rate should also be global if it is synced via MIDI. This frees one value in the SysEx dump which can be used for filter keytracking :) Best Regards, Thorsten.

Yes, it's a software feature. Currently it only works for the AOUT and 6581. For the 8580 I have to add a second interpolation routine, since the output curve is different. Before the next release I have to solve two things: the second interpolation (I will rewrite the routine, so that it can use two different parameter sets), and the filter keytracking issue (it works fine, but there is no place anymore within the Sysex data structure to store this parameter, currently I'm using the ENV2 curve value to control the tracking - I have to find a compatible solution - somehow) Best Regards, Thorsten.

Hi, You only need to invert the outgoing values. In MBLC, this can be done in lc_leddigits.inc, search for "call MIOS_DOUT_SRSet", and add "xorlw 0xff" before this function call in order to invert the content of WREG Best Regards, Thorsten.

Good news: in the meantime I found a solution to overcome this rough CC resolution: I've implemented an interpolation algorithm for the filter, which is just an envelope generator with dynamic attack/decay rate. The rate can be determined by measuring the time between two changes, and the difference between the two values - very simple. I found out, that such an interpolation is a *must* once a filter with high resonance is controlled, therefore I've created an example with the CEM3378 to demonstrate the difference. -> http://www.midibox.org/midibox_sid/mbsid_filter_interpolation.mp3 1st part: filter sweep without interpolation 2nd part: filter sweep with interpolation 3rd part: same like 1, but with delay Fx 4th part: same like 2, but with delay Fx The graphical representation of the CC sweep: (interpolation can be disabled with Sound Engine Option 2 - for the guys who like this typical 8bit effect ;-)) Best Regards, Thorsten.

hm... and do you notice any change at the unmultiplexed AOUT output #1 when you are sending CC#91 value 0..127 over channel #1 .. #8? You could also disable the AMUX feature for this test, this makes it easier. In this case AOUT output #1 should be directly controlable with CC#91 Channel #1, output #2 over channel #2, etc. (no change in midibox64.ini is required, the outputs directly correspond to the events specified for the analog inputs) Best Regards, Thorsten.

Hi Martin, did you enable the SHX8 module in main.asm like described at http://www.ucapps.de/mbhp_shx8.html? (search for "note") Best Regards, Thorsten.

There shouldn't be a delay in best case, because all inputs are captured at the same moment. But since the inputs are asynchronous signals, it can happen that the transition on one input won't be notified at the same cycle like the transition on the other input. This leads to the fact that the worst case delay is not pretictable. And you will notice another problem: let's assume you really want to combine a functional with a layer button. When you are pressing such a combined button, the layer function must be executed before the Note On event But when you are releasing the button, the Note Off event must be sent before the layer is switched back. Third point: you would have to disable the debouncing feature in order to get this working, because it also adds a more or less unpretictable delay. Without this feature, you have to debounce each single button via hardware. Workaround: if the layers would be switched with an IO pin, debouncing could still be used. However, this requires some changes in the software... Conclusion: there is no proper way to multiplex the layers via hardware, the only proper way is to re-write the software. Best Regards, Thorsten. P.S.: I guess that now I understand what you are planning to do. The reason why I haven't thought about such a solution is, that from designers point of view this is a usage mode which cannot work.

Yes, with layers you are switching between different button/LED assignments. It doesn't matter which functions are assigned, these are just IDs which are specified in the two tables (C version: three tables) Hold means, that the alternative table is used so long the button is pressed. There are also alternative behaviours, like toggle (press once: Layer B, press again: Layer A) or switch (one button for Layer A, one for Layer B). You could also left out this feature, in this case you can only use the functions specified in the first table. However, as you already noticed, there are some spare pins. Thats my own setup, I haven't changed it. I only tried to tell you, that my own box has less buttons than an original Logic Control, and since I made the additional button/LED functions reachable with a second layer, thats no issue for me. In general you can assign the functions to the inputs/outputs like you want. So, just put your personal most important parameters into the first layer, and everything else into the second layer. I'm sure that you can live with this solution! MIOS limits the number of maximum DINs to 128 - there is no (easy) way to add more digital inputs, and there is especially no way which will be supported from my side (it was hard enough to force people not to demand for more more MORE! buttons each time I made some extensions ;-) Best Regards, Thorsten.