TK.

I can use the box properly with my ALPS faders, also the calibration tool works ok. All faders are following the first fader - not with the same speed, but they reach their position with the values documented at the MF page (ALPS RSAON11M9: 7.5V, Period 3, Duty Cycle 1) Maybe I should mention that I'm using the faders since a long time. Maybe brand new faders have a higher mechanical resistance, which lowers than more you are moving the sliders (something like a burn-in ;-)) Best Regards, Thorsten.

Re-using this existing table was the idea of Jess D. Skov-Nielsen :) TB303 mode: implementation is finished, I don't plan more features for the next official release. Currently I'm a little bit out of ideas for demo sequences. I also don't have a clear plan, in which form the tutorial could be useful and wouldn't produce even more questions. Maybe it makes sense to start the tutorial in the Wiki as some kind of living document which gives a sufficient overview about the parameters at the beginning, and detailed infos once people really want to know about this - is anybody interested in creating TB303 demos? Best Regards, Thorsten.

Ja, dank JACK. Doch Linux ist bei mir ein schwieriges Thema - beruflich arbeite ich ausschliesslich unter Unix (Linux/Solaris) - einzige Ausnahme: Powerpoint-Folien. Zuhause zum groessten Teil - doch wenn es um Audio geht, muss ich notgedrungen Windows booten, nicht zuletzt wegen Logic und Reaktor (schliesslich habe ich dafuer bezahlt, und unter Linux gibt es nach wie vor keinen wirklich adaequaten Ersatz) Werde ich zwar als Fun-Projekt irgendwann einmal zuende bringen (zumindest MIDI IO und Businterface stehen schon), doch bezweifle ich, dass Microsoft jemals einen wirklich perfekten USB-MIDI Treiber zur Verfuegung stellen wird - somit haelt sich der Nutzwert in Grenzen. Es sei denn, man findet sich mit den Kompromissen ab (oder man rafft sich zusammen, und arbeitet sich in die USB-Treiber-Thematik ein :-/ ) Gruss, Thorsten.

maybe I forgot to recompile the application with TOUCH_SENSOR_MODE 1? Could you please check the setting in main.h, and type "make" again? Best Regards, Thorsten.

I also thought about this possibility, on the other hand Lide wrote, that 0-127 is sent with one half. A logarithmic pot would reach 80 or so, but not 127 at the middle But if the description is not detailed enough, then you are right: it could be a pot with log behaviour Best Regards, Thorsten.

Just open "sid_sw.inc" and search for "SIDSW_Filter_CBM8580", you will find the code which gets the mapped value from SID_FRQ_TABLE. This table is located in sid_frq_table.inc, and is normaly used for the MIDI Note->Oscillator Frequency calculation. So, it's not a good idea to change this one. Duplicating this table is also not possible, since it takes 256 bytes - this is ca. the amount of memory which is still free in the application. So, you could downstrip the MBSID application, means: remove features which are not used. But this is not trivial Please understand that I cannot provide the exact informations, how to do this for certain functions, it would always result into a lot of effort at my side to find out the possibilities which save 20..30 bytes per function - it already took a lot of effort to put all this TB303 stuff into a project which was already out of memory. In between 2 weekends I rewrote the whole control surface handler, just to save ca. 500 bytes (I'm proud that it still works like before without any bug). And this memory was filled by the new code. Another way would to wait for a full functional PIC18F4620 (like I). It provides an internal 64k flash, which means, that you could store 128 different filter tables in there (or some additional features ;-)) Best Regards, Thorsten.

Since you know about programming - here the mapping CC->SID Filter value when the 8580 Filter flag is set: CC | SID_FC 8580 00 | 0000 01 | 0000 02 | 0000 03 | 0000 04 | 0000 05 | 0000 06 | 0000 07 | 0000 08 | 0001 09 | 0001 0A | 0001 0B | 0001 0C | 0001 0D | 0001 0E | 0001 0F | 0002 10 | 0002 11 | 0002 12 | 0002 13 | 0002 14 | 0003 15 | 0003 16 | 0003 17 | 0003 18 | 0004 19 | 0004 1A | 0004 1B | 0005 1C | 0005 1D | 0005 1E | 0006 1F | 0006 20 | 0007 21 | 0007 22 | 0008 23 | 0008 24 | 0009 25 | 0009 26 | 000A 27 | 000B 28 | 000B 29 | 000C 2A | 000D 2B | 000E 2C | 000F 2D | 0010 2E | 0011 2F | 0012 30 | 0013 31 | 0014 32 | 0015 33 | 0017 34 | 0018 35 | 001A 36 | 001B 37 | 001D 38 | 001F 39 | 0021 3A | 0023 3B | 0025 3C | 0027 3D | 002A 3E | 002C 3F | 002F 40 | 0032 41 | 0035 42 | 0038 43 | 003C 44 | 003F 45 | 0043 46 | 0047 47 | 004B 48 | 0050 49 | 0055 4A | 005A 4B | 005F 4C | 0065 4D | 006B 4E | 0072 4F | 0079 50 | 0080 51 | 0088 52 | 0090 53 | 0098 54 | 00A2 55 | 00AB 56 | 00B6 57 | 00C0 58 | 00CC 59 | 00D8 5A | 00E5 5B | 00F3 5C | 0101 5D | 0111 5E | 0121 5F | 0132 60 | 0145 61 | 0158 62 | 016D 63 | 0182 64 | 019A 65 | 01B2 66 | 01CC 67 | 01E7 68 | 0204 69 | 0223 6A | 0244 6B | 0266 6C | 028B 6D | 02B2 6E | 02DB 6F | 0306 70 | 0335 71 | 0365 72 | 0399 73 | 03D0 74 | 040A 75 | 0448 76 | 0489 77 | 04CE 78 | 0517 79 | 0565 7A | 05B7 7B | 060E 7C | 066B 7D | 06CC 7E | 0734 7F | 07A2 [/code] [code] CC | SID_FC 6581 00 | 0000 01 | 0010 02 | 0020 03 | 0030 04 | 0040 05 | 0050 06 | 0060 07 | 0070 08 | 0080 09 | 0090 0A | 00A0 0B | 00B0 0C | 00C0 0D | 00D0 0E | 00E0 0F | 00F0 10 | 0100 11 | 0110 12 | 0120 13 | 0130 14 | 0140 15 | 0150 16 | 0160 17 | 0170 18 | 0180 19 | 0190 1A | 01A0 1B | 01B0 1C | 01C0 1D | 01D0 1E | 01E0 1F | 01F0 20 | 0200 21 | 0210 22 | 0220 23 | 0230 24 | 0240 25 | 0250 26 | 0260 27 | 0270 28 | 0280 29 | 0290 2A | 02A0 2B | 02B0 2C | 02C0 2D | 02D0 2E | 02E0 2F | 02F0 30 | 0300 31 | 0310 32 | 0320 33 | 0330 34 | 0340 35 | 0350 36 | 0360 37 | 0370 38 | 0380 39 | 0390 3A | 03A0 3B | 03B0 3C | 03C0 3D | 03D0 3E | 03E0 3F | 03F0 40 | 0400 41 | 0410 42 | 0420 43 | 0430 44 | 0440 45 | 0450 46 | 0460 47 | 0470 48 | 0480 49 | 0490 4A | 04A0 4B | 04B0 4C | 04C0 4D | 04D0 4E | 04E0 4F | 04F0 50 | 0500 51 | 0510 52 | 0520 53 | 0530 54 | 0540 55 | 0550 56 | 0560 57 | 0570 58 | 0580 59 | 0590 5A | 05A0 5B | 05B0 5C | 05C0 5D | 05D0 5E | 05E0 5F | 05F0 60 | 0600 61 | 0610 62 | 0620 63 | 0630 64 | 0640 65 | 0650 66 | 0660 67 | 0670 68 | 0680 69 | 0690 6A | 06A0 6B | 06B0 6C | 06C0 6D | 06D0 6E | 06E0 6F | 06F0 70 | 0700 71 | 0710 72 | 0720 73 | 0730 74 | 0740 75 | 0750 76 | 0760 77 | 0770 78 | 0780 79 | 0790 7A | 07A0 7B | 07B0 7C | 07C0 7D | 07D0 7E | 07E0 7F | 07F0 the interpolation smooths down the changes, but as you can see in the 8580 table, there is not that much headroom at the lower CC range Best Regards, Thorsten. FAQMARKER

MBHP_AOUT_LC layout:

thats what I told you one week ago ;-) If it helps: the SID provides a 11bit register for filter cutoff frequency, this means a range from 0x000-0x7ff is available. Sounds perfect, but the "internal" filter control curve of the 8580 is not linear, and the change from 0x000 to 0x001 is hearable! In order to linearize the curve (requirement for proper ENV/LFO modulation), 0x000 is mapped to a certain range. When you are incrementing the CutOff CC by +8 or so, and when you are hearing the first step, the CutOff register has been switched to 0x001 (this mapping is, what you are switching on with the 8580 filter flag). Values over 0x008 don't cause this steppiness effect anymore, in addition, higher CC# cause bigger changes in the filter cutoff register, but these changes are very smooth (no steppiness) - especially, since MBSID provides interpolation Nearly every 6 months a guy like you blames about ostensible software imperfections, so this is nothing new to me. This should also explain, why I'm reacting a little bit shirty in the meantime... Best Regards, Thorsten.

the speed is already variable, the speed is determined by measuring the time between the last and the current change Maybe I should highlight again, that the 8580 resolution and non-linearity problem is NOT a software problem! this special 8580 stepiness within the low range (and not the one I fixed via interpolation) is caused by the 8580 hardware implementation, it cannot be improved via software, no way - really - it's unsolvable! at least the 6581 and AOUT filter curves are very smooth now :) Best Regards, Thorsten.

no additional knobs or switches are required on the control surface, otherwise I would have mentioned it. See also this article http://www.midibox.org/forum/index.php?topic=5561.msg34212#msg34212 Best Regards, Thorsten.

You need a MBHP_AOUT_LC module (low-cost DAC) A schematic can now be found here: http://www.ucapps.de/mbhp/mbhp_aout_lc.pdf PCB Layout will also be provided (sooner or later) Best Regards, Thorsten.

Take care that the interrupt routine doesn't use the same resources like the main program, otherwise there could be unwanted influences. In general on such a situation, where you don't know from where a strange effect is coming from, it makes sense to disable parts of the code step-by-step (!) in order to find out, which one of the parts is causing the problem. This means, that you have to reprogram the firmware several times. It doesn't make fun with the PIC16F87x (without MIOS bootstrap loader), but propably this is the fastest way anyhow Best Regards, Thorsten.

Hi, the latest unofficial release can be found here: http://www.ucapps.de/mios/midibox_sid_v1_7_303beta10.zip Informations about the CV output routing can be found in CHANGELOG.txt, informations about future extensions are spreaded over several threads. In general this information about MBSID V2 (and the reason why I'm not able to begin with the next step) could be interesting to know http://www.midibox.org/forum/index.php?topic=5561.msg34212#msg34212 Best Regards, Thorsten.

You could use MIDIO128 for such a test Best Regards, Thorsten.

Hi, is your box stuffed with an AIN module, or did you connect the pot directly to an analog input of the core? Anyhow, such parameters can be configured in main.asm Best Regards, Thorsten.

Hi, connect all unused analog inputs to ground Best Regards, Thorsten.

Hi, no, a new bootstrap loader is not required - I guess that you missed the information, that MIOS has to be uploaded within 2 seconds after power-on? This is due to safety reasons See also http://www.ucapps.de/mios_bootstrap.html, search for "The whole upload procedure". Best Regards, Thorsten.

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.