TK.

yes No, you can't. The trigger flag has no effect without the sync flag. See SIDSE_B_SYNC_LFO1_Skip and SIDSE_B_SYNC_LFO2_Skip. And on the other hand: a LFO resynchronisation is required anyhow to process a whole LFO period, so I don't see a reason why it should make sense to use Oneshot without Sync. If you want to realize an oneshot mode, which works independent from the played notes, some more changes are required. The existing code gives you some hints. Best Regards, Thorsten.

Oneshot LFOs will be restarted with the gate. Legato Mode: you need to release all keys, and play a new note Mono Mode: with each new note Sequencer: when a note is not tied (no retrigger on slided notes) In all modes, the LFO Sync Flag needs to be set in addition It currently doesn't work for the right channel bassline. I know about this, no bug reports required. These inconsitencies came in with the latest changes in the multi engine (improved poly handling), this handling will be deactivated whenever bassline engine reuses code from multi engine. There is a similar issue with some parameters of the right channel envelope... In order to retrigger the LFOs, you need to set the flag SID_SE_TRG_EVNT_H, SID_TRG_TARGET_H_L1 for left channel LFOs, and SID_SE_TRG_EVNT_H, SID_TRG_TARGET_H_L4 for right channel LFOs (remember: right channel LFO handling currently doesn't work properly) If this doesn't make sense to you, I cannot give you additional tips, as nobody understands them anyway ;) Best Regards, Thorsten.

Will be fixed as well... Best Regards, Thorsten.

fixed...

Der MIDI-Kanal befindet sich in den unteren 4bit des Status-Bytes Moegliche Werte: 0xb0 (fuer Kanal 1) bis 0xbf (fuer Kanal 16) Das koennte man auch so schreiben: "0xb0 + kanal_von_0_gezaehlt" wobei "kanal_von_0_gezaehlt" ein Wert zwischen (dezimal) 0 und 15 sein sollte. In Deinem Anwendungsfall (11 Fader, pin == 0..10) koenntest Du den Kanal wie folgt bestimmen: [tt] MIOS_MIDI_TxBufferPut(0xb0 + pin); MIOS_MIDI_TxBufferPut(07); MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); [/tt] Gruss, Thorsten.

Nice "Blofeld" format! :) Best Regards, Thorsten.

A direct mapping of incoming SysEx parameter changes to CS items isn't possible without a lot of additional program code+map tables, or a lot of calculations, which would affect the performance of the synth engine. I guess, that nobody would really like such a visualisation feature which leads to drawbacks at the audible side, or which would prevent me from adding new features in future because of a completely allocated flash But - maybe a more powerful, because more flexible option: it would be possible to integrate a "remote control" function for button and rotary encoder functions. Are you able to send relative CCs with your MIDI controller? Best Regards, Thorsten.

Wow! :) Gruss, Thorsten.

So long an encoder is in normal mode, you won't notice any acceleration effect, because MIDI events are sent faster than the time between the "clicks" Once you are using "fast speed" mode, the incrementer changes as specified here MIOS_ENC_SPEED_FAST ~~~~~~~~~~~~~~~~~~~ // in this speed mode the increment value depends on the // rotational speed based on the following formula: // speed_ctr: decremented with every update cycle // (-> MIOS_SRIO_UpdateFrqSet) // (normaly 1 ms) to measure the time between // two encoder steps // Init value: 0x7f // reaches 0x00 after 127 update cycles // (normaly after 127 ms) // <parameter>: specified with the MIOS_ENC_SpeedSet // // function, allowed values: // 0 (fast) -> divider = 2^(7-0) = 128 // 1 (faster) -> divider = 2^(7-1) = 64 // ... // 7 (fastest) -> divider = 2^(7-7) = 1 // -> // incrementer = speed_ctr / (2^(7-parameter)) // set speed for encoder #0 to "fast", speed exponent value is 2 MIOS_ENC_SpeedSet(0, MIOS_ENC_SPEED_FAST, 2); [/code] So, I don't know why people are not searching in the MIOS function reference and in existing C examples? Sometimes, it really seems to me as it was wasted effort to write down all the details, because people will ask in the forum anyhow :/ Best Regards, Thorsten.

try the coding example, it is doing exactly for what you are searching for! Best Regards, Thorsten.

Das war ein Konvertierungsfehler in midio128_din.inc Unter http://www.ucapps.de/mios_download.html befindet sich nun der update Gruss, Thorsten.

Unter http://www.ucapps.de/mios_download.html Gruss, Thorsten.

If the first DIN sends multiple MIDI events, it seems to be a problem with the RC or SC clock line Some time ago, I wrote a troubleshooting guide which should help to find the wiring or soldering error: http://www.midibox.org/dokuwiki/din_module Best Regards, Thorsten.

The "click" happens since the DC offset changes at the audio output whenever different waveforms or filter modes are selected. With 6581, this effect is more dramatical than with 6582/8580. Unfortunately different volume values cause a DC offset change as well, otherwise MBSID could simply fade out/in the volume whenever a new patch is selected... Best Regards, Thorsten.

You can change the clock divider in the BPM menu. By default it's 4 for 24ppqn If you set it to 2, you get 48 ppqn With 1 you get 96 ppqn A start/stop signal is provided as well. The IO pin is specified in the setup_*.asm file Best Regards, Thorsten.

You have to replace the PIC18F452 by a PIC18F4620 (you could buy it with preburned bootloader from SmashTV), and you have to add a 1k pull-up resistor to J4:RC Best Regards, Thorsten.

Although it isn't standard, most software supports various "relative CC" event formats, and it's easy to implement this in C. However, this seems to be a double-post, Ultra asked for the same: http://www.midibox.org/forum/index.php/topic,11254.msg88492.html#msg88492 Best Regards, Thorsten.

Did you already try this example? -> http://www.ucapps.de/mios_c_send_enc_rel.html It sends relative events (0x40 +/- <speed>) - if you need a different format, just change the ENC_NotifyChange() function. If encoders are still too slow, incresse the divider setting in MIOS_ENC_SpeedSet(), e.g. use 4 instead of 2 (7 is maximum) No other changes are required, especially no hacks with a timer function or similar - everything is already provided by MIOS Best Regards, Thorsten.

Forgot to mention the Skill/Feature ratio: [tt] Required Skills ^ | ************* | *** | ** | * | * | * | * | * |* <--- your application is here |* +------------------------> Features [/tt]

[tt] [####--------------------------------] Required Programming Skills Newbie Expert [/tt] Best Regards, Thorsten.

Ok, finally I got the point. But wouldn't it be more consequential to display the current parameter assignment in full text (instead of the parameter number) when the item is selected (-> the selection button below the item is pushed)? I'm sure, that if the first Inc/Dec would be omitted for this particular menu item, it wouldn't take so long, until the first users would start to report a pseudo bug. Best Regards, Thorsten.

Could it be, that you mean a "slow" function which ensures, that even a fast encoder movement only increments/decrements a single step? Just press the SHIFT button and move the encoder! Alternatively, just don't move the encoder so fast for fine-tuning a parameter (wait ca. 0.2 seconds before moving to the next detent) - thats how I'm changing the Pa1 parameter, and it works great for me. Wilba: this is in conflict with the requirement to change multiple parameters the same time (e.g. CutOff with the right hand, Filter Decay with the left hand). I could add such a "encoder tick filter" function easily, but I would disable it by default, because I don't like it. Best Regards, Thorsten.

Wenn Du die uart_* Funktionen selber programmiert hast, solltest Du eigentlich den Unterschied zwischen einem String und Charactern (bzw. Bytes) kennen... Gruss, Thorsten.