TK.

Hi, you could send values from the Tick() hook - by using a static variable you can ensure that the values will only be sent once after startup. Something like this (untested code) ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS in the mainloop when nothing else is to do ///////////////////////////////////////////////////////////////////////////// void Tick(void) __wparam { static unsigned char ain_sent = 0; if( ain_sent == 0 ) { unsigned char pin; unsigned char num_ain = MIOS_AIN_NumberGet(); ain_sent = 1; // only sent once after startup for(pin=0; pin < num_ain; ++pin) { MIOS_MIDI_TxBufferPut(0xb0); // CC at channel 1 MIOS_MIDI_TxBufferPut(pin); // pin number corresponds to CC number MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); } } } Best Regards, Thorsten.

Hi Stahl, thanks for the confirmation, the comment is corrected now in the source code Best Regards, Thorsten.

Discussions about Wavetables now here:

Great! New v2.046 version now officially released :) Best Regards, Thorsten.

(Almost) well done! :) I would propose to define a 13th step (at position #12) which transposes by +0 (-> no transpose), and to set the loop point there. This ensures it won't be transposed further. Alternatively try Oneshot mode. yes Are you using this PSU? https://www.c64psu.com/c64psu/43-commodore-64-c64-psu-power-supply.html#/37-ac_cable-eu I noticed that the 5V output sometimes only delivers ca. 4.5V, which is too low and can cause random glitches. Also display backlight becomes darker. Power-cycling the PSU normally helps to get it stable again. Best Regards, Thorsten. P.S.: I will move the wavetable topic to a separate thread, because it's unrelated to the Ctrlr Panel

The links listed here: http://ucapps.de/midibox_sid_manual.html are working at my end - which page do you mean exactly? Yes, I'm aware that WTs are harder to program. People have to learn hexadecimal numbers... a good GUI design could hide this complexity and make WTs more accessible, but 1) Ctrlr limitations have to be considered and 2) it has to be consider that actually 4 wavetables are available with inididual start/end/loop point which can be anywhere in the 128 steps table. If you limit such features just to simplify the GUI (like in Insidious), it would mean that WTs in some patches can't be edited properly. Hence we need a solution which is easy to use and universal enough. Concerning usage examples: did you already find the "first steps" guide - search for "Wavetable Sequencer": http://ucapps.de/midibox_sid_manual_fs.html There are also some legacy tutorials for MBSID V1 which show how to work with arpeggios: http://ucapps.de/howto_sid_wavetables_2.html http://ucapps.de/howto_sid_wavetables_3.html Best Regards, Thorsten.

Thank you both - as you noticed, I'm solving some topics, but please don't expect too much in the next months, I just want to ensure that we are still able to play with our MIDIboxes (and of course enhance them) the next years Need some time to think about this - The MBSIDV2 WT handler offers much more flexibility than the Reaktor based solution, and such a nice looking GUI won't be possible to implement with the given capabilities of Ctrlr. So, it's already clear: if I come up with a solution, it will be very pragmatic... Best Regards, Thorsten.

Interesting! You are totally right, and it seems that nobody complained about this before, resp. if so it didn't raise my attention ;-) It's fixed now, please try: http://www.ucapps.de/mios/midibox_sid_v2_046.zip I think that I should also release this version, the official one is v2_044, but some minor changes have been done in the last years so that it's worth to make it available for everybody who uses the pre-built version. Please let me know if it works with your hardware. Best Regards, Thorsten.

Ok, I've to admit that I haven't checked the current state of the driver before my reply Unfortunately it isn't available - last posting about this activity was more than 10 years ago: I fear that nobody can help you to get it running :-( Best Regards, Thorsten.

Finally Ctrlr is perfectly working with MBSID under MacOS (Intel and Apple Silicon) again! :) The application and migrated MIDIbox_SID_V2.bpanelz file can be found in this package: -> http://www.ucapps.de/midibox_sid/ctrlr/Ctrlr__tk_changes_for_midibox__20231026.zip Best Regards, Thorsten.

Yes, this one should work Here the interconnections: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?media=neonking:ssd1322-pinout.jpg In order to select the display in MIOS32, upload the Bootloader Update Application and enter: set lcd_type GLCD_SSD1322 set lcd_num_x 1 set lcd_num_y 1 set lcd_width 256 set lcd_height 64 store Thereafter upload the MIDIbox NG application again -> display should show some meaningful messages Best Regards, Thorsten.

Hi, in the last days I troubleshooted the MIDIbox SID panel with the latest CTRLR sources which are available on Github. This resulted into: a solution for newer Macs with Apple Silicon: https://github.com/RomanKubiak/ctrlr/issues/560#issuecomment-1771700555 a small source code change to get the "ui" flag working again because my panel relies on this feature, which vanished some years ago for whatever reason: https://github.com/RomanKubiak/ctrlr/pull/573 some LUA script changes to get the panel compatible I will do some testing in the next days to ensure that all parameters are working, and I have to find a way to build AUs However, I will only be able to provide a MacOS version. PC users might be interested on the "fixed version" as well. Therefore the question: has anybody the knowledge to build CTRLR with my source code changes on a PC? Best Regards, Thorsten.

There is hope! Two days ago a new JUCE version has been released with an interesting message: #if ((defined (MAC_OS_X_VERSION_MIN_REQUIRED) \ && MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_VERSION_13_0) \ || (defined (__IPHONE_OS_VERSION_MIN_REQUIRED) \ && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_15_0)) // This is an error because the linker _will_ produce a binary that is // broken on older platforms static_assert (std::string_view (__clang_version__) != std::string_view ("15.0.0 (clang-1500.0.40.1)"), "The new linker introduced in Xcode 15.0 will produce " "broken binaries when targeting older platforms.\n" "To work around this issue, bump your deployment target to " "macOS 13 or iOS 15, re-enable the old linker by adding " "'-Wl,-ld_classic' to your link flags, or update to Xcode " "15.1.\n" "Once you've selected a workaround, you can add " "JUCE_SILENCE_XCODE_15_LINKER_WARNING to your preprocessor " "definitions to silence this warning."); #endif #endif So, here a new binary build with latest JUCE and -Wl,-ld_classic flags, let me know if this works: -> http://www.ucapps.de/mios_studio/MIOS_Studio_2_4_9_r3.app.zip Best Regards, Thorsten.

Hi Zam, thanks for the feedback - although it worries me ;) The crash report indicates that something is going wrong before the actual application code has been started. I haven't seen this before, and therefore don't have a solution (yet). What would be interesting: what happens if you start MIOS Studio from a terminal: MIOS_Studio.app/Contents/MacOS/MIOS_Studio --batch Best Regards, Thorsten.

Older versions can be found in the archive: http://ucapps.de/mios32/backup/ Best Regards, Thorsten.