TK.

Thanks for the input! To the ASCIImatic: it looks like an envelope follower, and this is propably what I have to do for a more accurate slide/glide/portamento/whatever, regardless if it is linear or exponential. You are right so long the available resources don't matter. E.g., the simplest way to create a capacitor charging curve is the use of a precalculated table, and to scale the output values depending on the difference between the starting and end frequency. Problem: 256 16bit entries consume 512 bytes, so much is not free. Another way: re-using the existing code, which produces a non-linear curve. Problem here: it requires at least 7 bytes per oscillator, makes 21 for all. So many bytes are not free anymore (within the reserved range for SID variables) The way I will propably go: an optional switch which allows to use ENV2 for portamento. By doing so, the rate as well as the curve is freely controllable, and maybe the release rate allows to add some more analog behaviour (frequency change when cap not completely charged). thats an interesting point - maybe it can be realized without much effort by re-using ENV2 (gain is free adjustable) Let's see... Best Regards, Thorsten.

For the records: this is, how a linear slide sounds like (delta = abs(target_frequency-current_frequency) / slide_rate http://www.ucapps.de/tmp/mbsid_constant_slide2.mp3 Best Regards, Thorsten.

Haven't tried a linear slide yet, since I think that it doesn't lead to the desired effect. Guess what happens when the frequency sweeps from a high to low note. In the meantime I think, that the exponential charging and decharging curve of a capacitor has to be modelled. I did something similar with the envelope curve feature (algorithm found by Jess D. Skov-Nielsen), maybe using the same for portamento will result into the desired effect: Best Regards, Thorsten.

only lamers (and managers ;-)) are using excel. At the begining I used this short perl program - I made a lot of modifications, which haven't been saved, but I guess that it helps you: my $porta_rate1 = 0.1; my $current_frq = 220; my $target_frq = 2*440; #my $target_frq = 4*440; #my $target_frq = 8*440; my $porta_rate2 = $target_frq / $current_frq; my $porta_rate = $porta_rate1 * $porta_rate2; printf "Current Frequency: %5d\n", $current_frq; printf "Target Frequency: %5d\n", $target_frq; printf "Portamento Rate: %5.4f * %5.4f = %5.4f\n", $porta_rate1, $porta_rate2, $porta_rate; my $step = 0; while( $current_frq < $target_frq ) { ++$step; $current_frq += $current_frq * $porta_rate; if( $current_frq > $target_frq ) { $current_frq = $target_frq; } printf "%6.3f mS: %d\n", 0.8192 * $step, $current_frq; } [/code] then the 5 semitones modification will be skipped. it seems, that at least rebirth is doing the same, maybe also because they payed more attention for the sound result, than for accuracy. Not sure, how a real TB303 behaves here. It should The idea isn't that bad, it would mean, that higher notes are sweeped more slowly than lower notes. Best Regards, Thorsten.

Suppa! Tja, das Problem im Forum ist, dass in den alten Artikel neue Erkenntnisse nicht nachgetragen werden. Vielleicht sollte ich den .hex hack einfach mal auf der MBHP_BURNER Seite dokumentieren... Gruss, Thorsten.

No, a wrongly connected encoder cannot cause this behaviour. MIDIO128 sends all 128 events which are assigned to the digital inputs. So, it seems, that there is a problem with the clock line (in simple words: if the shift registers cannot be clocked, the first pin in the chain will send all events at once) Either the clock line is not connected properly, or there is a short. This can be measured very easily: put all ICs (PIC, 74HC165) out of the socket, and use your measure to check the contacts (if it provides a "beeper", then use it, otherwise use the ohm-meter function). Check: - Core J8:SC against ground: no contact - Core J8:RC against ground: no contact - Core J8:SI against ground: no contact - Core J8:SC against J8:RC and J8:SC against J8:SI: no contact - Core J8:SC to J1:SC of the DIN module: there must be a contact Best Regards, Thorsten.

I've moved your post to the old one, because it's not really useful when you spread your questions over the whole forum. If you have some programming skills, you should be able to merge the C based MIDIbox LC application with the DIN Velocity project (this is not trivial, but it works) Without programming skills, the easiest way is the use of two cores Best Regards, Thorsten.

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.