TK.

And here the result: http://www.ucapps.de/tmp/mbsid_constant_slide.mp3 In this sample, the slide always starts 5 semitones before the target note. Accordingly, the slide has a constant time :) Best Regards, Thorsten.

Forget the formulas: I just have started Rebirth, and it seems that a "constant time slide" is realized by transposing the starting value into a range which is close to the target note. Is this the typical TB303 slide effect? Best Regards, Thorsten.

There is a C based project which provides velocity sensitivity (-> http://www.midibox.org/forum/index.php?topic=5835.0), but some code need to be added in order to control analog inputs as well (-> http://www.ucapps.de/mios_c.html) Best Regards, Thorsten.

Hm... it sound nice on slow slides, but doesn't perform very well on fast slides. I will search for a new approach tomorrow (any idea?) Best Regards, Thorsten.

Hi, a DIN testsoftware is not required, just upload MIDIO128 - it sends an individual note event for each digital input Best Regards, Thorsten.

Much better: current_frq += int((current_frq * porta_rate) >> 16); porta_rate += int(((abs(target_frq-current_frq)>>8) * (porta_rate>>8)) >> 8); [/code] Mathematically not correct anymore, but the resulting sound is cool!!! :) Best Regards, Thorsten.

Despite of the small error in the formula (results are only correct with a slide from low to high frequency), it's mathematically correct, but the slide doesn't sound that good. I've the impression, that frequency changes must be higher at the beginning... Best Regards, Thorsten.

Currently I'm trying to find a formula which works without division, and which delivers not precise, but adequate results (in analog world nothing is precise anyhow ;-)) This one is promissing: current_frq += int((current_frq * porta_rate) >> 16); porta_rate += int(((target_frq>>8) * (porta_rate>>8)) >> 8); [/code] because it requires only a 16x16 multiplication (like the "normal" portamento function of MBSID), and a 8x8 multiplication (can be done within 1 CPU cylce) Best Regards, Thorsten.

And here another typical problem - propably the same one which I noticed last time: assumed that this formula is taken: current_frequency += current_frequency * rate_factor * freq_high/freq_low and assumed that we are *not* calculating with floating point values (the PIC is not a DSP...) then a slide between two octaves looks like this: [tt] Current Frequency: 440 Target Frequency: 880 Portamento Rate: 0.0100 * 2.0000 = 0.0200 0.819 mS: 448 1.638 mS: 457 2.458 mS: 466 3.277 mS: 476 4.096 mS: 485 4.915 mS: 495 5.734 mS: 505 6.554 mS: 515 7.373 mS: 525 8.192 mS: 536 9.011 mS: 547 9.830 mS: 558 10.650 mS: 569 11.469 mS: 580 12.288 mS: 592 13.107 mS: 604 13.926 mS: 616 14.746 mS: 628 15.565 mS: 640 16.384 mS: 653 17.203 mS: 666 18.022 mS: 680 18.842 mS: 693 19.661 mS: 707 20.480 mS: 721 21.299 mS: 736 22.118 mS: 751 22.938 mS: 766 23.757 mS: 781 24.576 mS: 796 25.395 mS: 812 26.214 mS: 829 27.034 mS: 845 27.853 mS: 862 28.672 mS: 879 29.491 mS: 880 [/tt] But a slide over three octaves looks like this: [tt] Current Frequency: 440 Target Frequency: 3520 Portamento Rate: 0.0100 * 8.0000 = 0.0800 0.819 mS: 475 1.638 mS: 513 2.458 mS: 554 3.277 mS: 598 4.096 mS: 646 4.915 mS: 698 5.734 mS: 754 6.554 mS: 814 7.373 mS: 879 8.192 mS: 949 9.011 mS: 1025 9.830 mS: 1107 10.650 mS: 1196 11.469 mS: 1292 12.288 mS: 1395 13.107 mS: 1507 13.926 mS: 1628 14.746 mS: 1758 15.565 mS: 1898 16.384 mS: 2050 17.203 mS: 2214 18.022 mS: 2392 18.842 mS: 2583 19.661 mS: 2790 20.480 mS: 3013 21.299 mS: 3254 22.118 mS: 3514 22.938 mS: 3520 [/tt] And this is a very short slide, the difference will be even more audible on slides around 500 mS and more :-/ Best Regards, Thorsten.

You could provide an option which allows to update the single patch of a slave directly. This could make sense on stereo sounds to improve fineadjusting without a control surface. Sidenote: the master sends a specific patch from a specific bankstick to the slave with "Bn 00 <bank> Cn <patch>", where n is the MIDI channel to which the slave has been assigned. I know, that this is proplematic if two or more cores are assigned to the same MIDI channel, but it's maybe worth to mention it. Best Regards, Thorsten.

I know what you mean, but this is what I already tried months ago, and the effect wasn't really good, because the result is far from the behaviour of the analog circuit, just because the formula is too much simplified (and it *must* be simple, since 16bit calculations are taking many many cycles on the PIC!). However, your post inspirated me to a nice solution, just let me try it out :) Best Regards, Thorsten.

Hi Matteo, I found out, that in the meantime it's possible to access getDeviceID() instead of getMIDIChannel() - the new release can be found here: http://www.ucapps.de/jsynthlib.html Best Regards, Thorsten.

I've created a new page, which describes a workaround for the annoying Java MIDI bug, and which contains a snapshot from the CVS with MIDIbox editor specific bugfixes: -> http://www.ucapps.de/jsynthlib.html Best Regards, Thorsten.

I second that - the non-linearity caused by unequal R values is higher. I guess that highest accuracy can only be achived by using integrated, laser-trimmed R ladders ($$$ - this is, what the MAX525 makes so expensive), or by using high precision Rs, which are normaly used for measuring instruments ($$$$$) Best Regards, Thorsten.

yes, I guess that in reality it would be faster. You are right, by using the old "slide rate factor", which was calculated at the time the slide has started, the effect would be more realistic. Maybe I should try this. unfortunately not, because the question is, how to transfer a "constant time slide" into the digital world. Ok, this evening I will try out Kokoon's suggestions Best Regards, Thorsten.

nothing happens, because there is propably no BankStick connected to the slave SID? (and this is the normal case, since only the master should be stuffed with a BankStick) Best Regards, Thorsten.

Just found one: http://c64-online.com/forum/index.php?&act=Downloads&CODE=02&id=226 (published in a C64 magazine ca, 16 years ago - hard to believe, how fast time passes by... ;-)) Best Regards, Thorsten.

yes, or a LED + resistor. Connect the cathode to ground, and the anode over a 220 Ohm...1k resistor to the pin which should be tested.

Discussion about future features has been moved to http://www.midibox.org/forum/index.php?topic=6075.0

Hi Jesper, In the "if" just check for 0xbf (which stands for CC, Channel 16) Don't write "case 0xb0", because this is a check for a masked value (evnt0 & 0xf0), the lower nibble is always 0 yes, you can store it in an array of "unsigned char" Which text is displayed by MIDI-Ox? Best Regards, Thorsten.

Let's split the thread... ;-)

Or MIDIbox SEQ, which is my most powerful arpeggiator implementation so far (see http://www.ucapps.de/midibox_seq_tutorial4.html), and it provides CV outs as well. I'm sure that I won't put this code into the MBCV, it would be wasted time. Instead I will just improve the MBSID arpeggiator a little - and not more! In fact, for myself the main intention behind the MBCV improvements is to get some more experiences with modulation/trigger routing in order to find out, what is possible with the PIC, and what not. These experiences will flow into the MIDIbox SID sound engine V2 (next year or so...). So, of course, it's useful to know which features other guys have realized in order to get some inspirations for future projects (than sooner I consider them, then more consistent the final engine), but my focus is definitely not to beat the others - I just want to have some fun! Best Regards, Thorsten.

An unknown reaction will happen. Propably you won't get any reply at all (the SysEx implementation is very primitive in order to have more memory free for powerful sound features) This is propably because the AUTO_DEVICE_ID flag in main.asm is set. I added this newbie friendly feature, since people were mostly confused about the MIOS Device ID and the SID Device ID. With AUTO_DEVICE_ID, the SID will automatically get the same ID like MIOS, and - of course - in this mode you are not able to change the ID anymore. If you really need this, then just set this flag to 0, but on the other hand: I don't know why you want to change it? Thats normal when you are changing the patch number of the master SID (the SysEx is routed internally). It only sends a dump (with the appr. device ID) when you are changing a patch of a slave. If the dump would be invalid, the SID wouldn't send an acknowledge (0F) at all. Acknowledge (0F) means, that the command has been regognized and processed. Which command do you mean exactly? is your second SID configured as master or slave? It's a slave when the device ID is != 0 (thats also one of those newbie friendly options). It's interesting thats newbies don't have problems with device IDs anymore since months, but now an expert stumbles over the auto features ;-) General suggestion: read the main.asm Best Regards, Thorsten.

Hi, no, such an option is not supported by MBLC, because J6 of the core is configured for the MBHP_MF module. But you could just build a second core module, and upload a different firmware (like MB64) which supports the AIN. It will cost you 20 EUR more, but it's the most flexible solution which doesn't require any software change. Best Regards, Thorsten.

This isn't so bad and brings some improvement. But what should happen if at the middle between previous and new note you decide to play another note? Let's say, C-1 to C-4 (factor 8 ), and while the frequency is sweeped and has reached the frequency around C-3, D-3 is played. What should happen then? A very long sweep from C-3 to D-3? Or just ignoring this side effect, which wouldn't happen when a slide is realized with analog components? Do you know, how other synths with a similar slide feature like the TB303 do react under such conditions? Best Regards, Thorsten. P.S.: thanks for your answer! At the time I wrote the initial posting, I already thought: if somebody will answer, then propably Kokoon! :-)