TK.

Yes, you are right. Only roll would work with triggers, but if you add a MIDI function (which is very easy), you could support velocity in this way: default 100, accent 127, flam: 64..127 Best Regards, Thorsten.

Mike has added the PIC16F88 adapter to the _V1 layout, so that the burner can be used for 40-pin and 18-pin devices. This enhanced version is now available in his shop (http://www.mikes-elektronikseite.com/), the layout is available at the http://www.ucapps.de/mbhp_burner.html page. Best Regards, Thorsten.

You should see the enable and RW line toggling during startup. If the LCD is not properly connected (e.g. signal lines swapped or a short), the driver is able to detect this (it polls the busy flag at D7), and finally gives up - the LCD won't be accessed in this case anymore, and the signals won't toggle anymore. So, just check the signals during the boot phase Best Regards, Thorsten.

It is, but the aout.c file needs some modifications - an existing application like MBSID or MBCV includes a "template", how to access the AOUT_LC module Best Regards, Thorsten.

There is an optocoupler test which allows you to check, if it is really broken: Best Regards, Thorsten.

Strange things happen, but ok... Yes, the MIDI data which is sent out during startup is ok - these are the patches for the slaves. The silent sound is the typical background noise of a 6581, the 8580 has a much better s/n ratio... You can improve it a little by connecting the audio in to ground so long it isn't used for external audio Best Regards, Thorsten.

Two comments from the programmers point of view: I think that the timings will be very relaxed, even with a large button/LED matrix, because it doesn't consume more CPU power, it only decreases the scan rate (e.g. on a 16x8 matrix, buttons will be scanned each 8 mS instead of each mS) - this is acceptable for such a device. Another point: I think that you can increase the number of steps very easily to 64. Here a calculation example: the gate of 8 steps can be combined in a single byte. This means, that 16 steps require 2 bytes, 32 steps 4 bytes, 64 steps 8 bytes So, 64 * 16 steps are 128 bytes, and this range can be easily accessed. Additional 64*16 bytes are required for the accent. Accordingly, a patch allocates 256 bytes, and this means, that 128 patches could be stored in each 32k BankStick What I'm missing a little is a "roll"/"flam" feature, it can be easily realised by sending 2 notes per step if the function is selected (like accent). However, this would also change the calculation for the patch size Best Regards, Thorsten.

The strange behaviour could be a bug in mbseq_v2_4b, I remember that I never tested it with analog pots. Best Regards, Thorsten.

It seems that the upload of .syx configuration data doesn't work with your setup (don't know if it is related to the LTC module, to the PC, or to the application). But since you are able to upload the application itself, you could also do the configuration directly in mb64e_presets.inc and rebuild a new .hex file, so that mk_syx doesn't need to be used Best Regards, Thorsten.

Ok, schematic was not up-to-date: Local: 11880 bytes, dated Sa 07 Jan 2006 18:13:24 CET. Remote: 11874 bytes, dated So 23 Okt 2005 21:11:32 CEST. [O]verwrite? [R]esume? [A]ppend to? [S]kip? [N]ew Name? [O!]verwrite all? [R!]esume all? [S!]kip all? [C]ancel > o mbhp_aout_lc.pdf: ETA: 0:00 11,60/ 11,60 kB 66,65 MB/s b [/code] Best Regards, Thorsten.

Thanks for the notification. I guess that in 2 months I will be ready to do some experiments with your application :) Best Regards, Thorsten.

Hi Moxi, I cannot find the mismatch, but maybe I'm just blind. Which resistor do you mean exactly? R50 and R52 are near the TL072, but they are 47k like expected Best Regards, Thorsten.

A configuration with 64 encoders and 64 buttons is not possible, since 64 encoders already allocate 128 pins. However, in setup_midibox64.asm you can find a tested configuration for 64 pots, 64 buttons and 32 encoders. A precompiled .hex file is also available - so you could upload it without reassembling. Best Regards, Thorsten.

Something what could be realized is the possibility to play tracks with a multiplier (so not only a divider). Since it will be possible to chain tracks, you will be able to combine 4 tracks and play them 4 times faster. This will result into a chain of 128 steps over 8 beats A track can send up to 3 CC values at the same time... enough room for controlling different waveforms at the same time. And all these nice progression parameters (steps back/forward, randomness, repeats, loops, etc...) will still work. Best Regards, Thorsten.

I splitted the posting to improve the documentation... Your idea to combine the steps and layers isn't that bad, but increasing the speed in which they are played will require to overwork the whole concept. In addition, the handling will be different in many menu pages. Things which are normaly obvious will become complicated, especially I hear already the question "Why does the sequencer behave so strange when I switch from any mode to this special "CC multistep mode"? And why does it send so strange values when I switch back during liveplaying? (We already had this issue with the drum mode, therefore I removed it, and adapted the overall concept so that it works better) I can only say: it just doesn't match with the whole concept - not only the programming concept, but also with the user interface. E.g., it won't be so easy anymore to use the progressive parameters, to determine which step should be played on an incoming MIDI position command, to use backward/pendulum/random parameters, etc... At the end I think that your idea cannot be adapted to the overall concept, and another firmware + another user interface (-> front panel) has to be developed in order to achieve best handling and not only a tinkering solution. Currently following values are available for each track: ;; track record structure SEQ_TRKMODEx EQU 0x00 ; track mode SEQ_TRKEVNTx EQU 0x01 ; first MIDI byte SEQ_TRKEVNTCONST1x EQU 0x02 ; event constant value #1 SEQ_TRKEVNTCONST2x EQU 0x03 ; event constant value #2 SEQ_TRKEVNTCONST3x EQU 0x04 ; event constant value #3 SEQ_TRKCHNx EQU 0x05 ; MIDI channel and port SEQ_TRKDIR1x EQU 0x06 ; track direction (mode and replay) SEQ_TRKDIR2x EQU 0x07 ; track direction (steps fwd and jump back) SEQ_TRKDIVx EQU 0x08 ; clock divider SEQ_TRKLENx EQU 0x09 ; track length SEQ_TRKTRANSPOCTx EQU 0x0a ; octave transpose value SEQ_TRKTRANSPSEMIx EQU 0x0b ; semitones transpose value SEQ_TRKGROOVEx EQU 0x0c ; groove mode and intensity SEQ_TRKMORPHx EQU 0x0d ; morph mode SEQ_TRKHUMANIZEx EQU 0x0e ; humanize mode and intensity SEQ_TRKSPARE1x EQU 0x0f ; spare SEQ_TRKSPARE2x EQU 0x10 SEQ_TRKSPARE3x EQU 0x11 SEQ_TRKSPARE4x EQU 0x12 SEQ_TRKSPARE5x EQU 0x13 SEQ_TRKMUTED0x EQU 0x14 ; muted steps 1-8 SEQ_TRKMUTED1x EQU 0x15 ; muted steps 9-16 SEQ_TRKMUTED2x EQU 0x16 ; muted steps 17-24 SEQ_TRKMUTED3x EQU 0x17 ; muted steps 25-32 SEQ_TRKSTEPCTRL1_0x EQU 0x18 ; step control 1 SEQ_TRKSTEPCTRL1_1x EQU 0x19 SEQ_TRKSTEPCTRL1_2x EQU 0x1a SEQ_TRKSTEPCTRL1_3x EQU 0x1b SEQ_TRKSTEPCTRL2_0x EQU 0x1c ; step control 2 SEQ_TRKSTEPCTRL2_1x EQU 0x1d SEQ_TRKSTEPCTRL2_2x EQU 0x1e SEQ_TRKSTEPCTRL2_3x EQU 0x1f [/code] where some of them already have a double or trible definition (e.g. the TRKSTEPCTRL* variables will be assignable to # Skip: skip/accent/glide/roll/random gate/random value). The purpose of the track constants are also different depending on the selected track mode. Best Regards, Thorsten.

this was a typo (see above), try it again...

Resistor: "1/4W 1,0k" 2200 uF/25V cap: "rad 2.200/25" 2200 uF/16V cap: "rad 2.200/16" seems that the search function of reichelt doesn't work so nice like months before... I will fix this in the order lists Best Regards, Thorsten.

You should search at ucapps.de as well ;-) http://www.ucapps.de/mios_c_send_ain.html Best Regards, Thorsten.

mostly clever usage of envelopes and LFOs are doing the same, sometimes even better than manual edited curves. You can control the ENV/LFOs parameters from MBSEQ V3 very easily. E.g., one single track can control three CC's at the same time, or you can assign a track to Note/Velocity and an additional CC (in this case, the length is statically). If this CC controls a modulation source of the synth, you are fine in most cases. I know, this doesn't help for all cases. But it's an alternative solution of which you propably haven't thought before... Best Regards, Thorsten.

Currently I don't have an imagination, how this should be realized user friendly... I mean: how should the user customize such a "screen and button layout" (step assignments to LCD and buttons), and would he really use it, or would he prefer the standard way because the configuration is too difficult and bad documented? So, if you could give me an exact usage example, how to configure this with the existing MBSEQ hardware (which menu, which encoders/buttons/etc...) I could think about how much effort it would be for me to integrate this. But at the end I think, that I never would use this by myself. So, there must be strong arguments for such a feature! ;-) This doesn't match with the concept and won't work. You can only quantisize with the given resolution while recording live, everything else will consume more memory than planned. Calculation example: currently a pattern consists of 4 tracks, there are 32 steps and 3 layers, makes 384 bytes. There are a lot of parameters for each track, which allocate 128 bytes in addition. So, a whole pattern takes 512 bytes. Accordingly, 64 patterns can be saved in each 32k BankStick, and 128 in each 64k BankStick. This is acceptable, and it can be especially handled very *very* fast now with the PIC18F4620 (in addition I integrated a cache mechanism, so that even the BankStick fetching time cannot be regognized anymore :)) But now your idea to save 16 values per step. This would mean, that each pattern has to allocate 16*384 + 128 = 6272 bytes, accordingly only 5 patterns (instead of 64!) could be saved in a 32k BankStick. And in addition, the step values couldn't be stored in RAM anymore. This is the biggest advantage of the v3 version, your idea would lead to the same situation like with v2 Hope that this makes my point of view more clear... Best Regards, Thorsten.

...and you've measured the voltage again when the SID is in the socket? I only ask to double check this, because - as mentioned above - when e.g. the voltage for a 6581 is lower than 11V, the SID behaves exactly like you've described. With the MBSID and the testtone application... Best Regards, Thorsten.

My thoughts: building a dedicated PCB for mounting two SIDs is much more error prone than building two MBHP_SID modules, because you will have more than 15..16 (or so) connections to the IC socket + an additional CS signal. Instead, two MBHP_SID modules are more compact, and you can stack them ("doubledecker") in order to save space in the case (it works, I already tried this in my C64 case to estimate, if I can build 8 SIDs into the case, or if I need to design a new PCB). Note that the second module doesn't need to be populated completely (the 12V/9V circuit can be used for both, or for all SID in the case modules). So, you would even don't save money when building an 2*SID adapter instead of using an additional MBHP_SID module, it would only increase the propability for loose contacts. Best Regards, Thorsten.

Just open mb64_midi.inc, search for "MB64_MIDI_SendButtonEvent". Here you can make your enhancements, because this functions knows about the button number, it prepares the MIDI event, and forwards it to MB64_MIDI_Send On the other hand: if you neither use the LCD menus (and therefore miss most of the specific MB64 features like MIDI learn, onscreen event editing, morphing), a C application is much easier for that what you are planning to do, and I guess that your work will be much better re-usable for other users. Because a) it's a nice programming example, b) C is easier to read and modify, c) you will see, that the program itself only consumes 2..4k at the end (you don't need most of the MB64 stuff), and d) you don't need to ask me where to find certain parts of hooks, switches, levers, etc... this is also time consuming for myself. So, it would propably be easier for both sides if you would build up an application from scratch. Best Regards, Thorsten.

P.S.: see map.h of the "analog_toolbox" application

Never add such custom functions into MIOS, it makes your application incompatible. Just write the function into a seperate .c or .asm or .inc file, this can be distributed very easily. On the other hand: in my own applications, I don't call functions for such special conversions at all. I mostly do the conversion directly, which is faster. In C you only need to write "value >> 2" to get the same effect, so why creating a function? Best Regards, Thorsten.