TK.

Why are you using "open"? This is a different approach. If you want to spawn without opening a terminal, then add a '&' to the command (normal unix approach) Usually this is not written into an alias, so write: ms & with the initially proposed alias: alias ms='/Applications/MIOS_Studio.app/Contents/MacOS/MIOS_Studio' (without "open") Best Regards, Thorsten.

This is probably related to a race condition while loading the files. Regardless of this, I wanted to allow something like if ^section == 0 set ^section 2 endif this would solve the issue on a more elegant way. Best Regards, Thorsten.

Problem is, that you are requesting so many features, that I'm not able to catch up at my side... ;-) I added your request to the wishlist, so that it doesn't get lost. Best Regards, Thorsten.

Danke fuer die Infos, jetzt sehe ich klarer, was Du moechtest. In der aktuellen Firmware gibt es nur zwei Modi, um mit einem Poti (bzw. analogen Sensor) Noten zu generieren 1) standardmaessig wuerde MBNG mit jeder Faderbewegung ein neues Note On event, jedoch kein Note Off event senden. Bedeutet: der Notenwert wird uebertragen, die zuvor gespielte Note bleibt jedoch haengen. Bei einem Mono-Synth wuerde das ausreichen, doch bei einem Poly-Synth macht sich das unangenehm bemerkbar 2) neuerdings (noch nicht released) gibt es auch einen Spezialmodus fuer Drucksensoren, bei dem einmalig ein Note On je nach AIN Eingangswert gesendet wird, und ein Note Off, wenn der Wert auf 0 sinkt (der Sensor also losgelassen wird), siehe auch: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fain_fsr.ngc Was Du jedoch sehr wahrscheinlich benoetigst, ist ein Modus, bei dem mit jeder Faderbewegung vor dem Note On (mit dem neuen Wert) noch ein Note Off gesendet wird. Das koennte ich noch einbauen - es waere sowieso eine interessante Option, auch im Zusammenhang mit Sensoren. Gruss, Thorsten.

Hi Steve, if the encoders are working fine in absolute mode, then this issue isn't hardware related. And the application should also run fine. You can verify this with the MIDI IN monitor in MIOS Studio: does it show the value 01 when the encoder is moved clockwise, and 7f when the encoder is moved counter-clockwise? Maybe your DAW expects a different format for the relative MIDI events, do you have any documentation about this? Best Regards, Thorsten.

(btw.: .rar is a bad format for exchanging files platform independent... you should prefer .zip) There are multiple errors: 1) the MF command is missing before n= 2) both modules are routed to the same configuration port - did you also configure separate device IDs in the PICs? The have to be != 0, and they have to be different for the two PICs. If you want to avoid the requirement to use the device ID != 0, then use USB2, 3 or 4 (because your MIOS32 core listens to device ID 0, but only on USB1 and IN1) If you want to avoid the requirement to use differennt device IDs for the PICs, then use config_port=USB2 for one, and config_port=USB3 for the other PIC 3) both modules are sending to the same MIDI channel - really? Which channel did you configure in the MF tool configuration? Best Regards, Thorsten.

Oh, these are very good news! It seems that everything is installed properly: the bootloader, MIOS and the MIDIbox SID Application, otherwise you wouldn't hear any sound at all. Now you would always be able to update the application via MIDI (if you want), but I guess that you are already using the latest firmware. yep! No, much more LEDs should be lit: (SID)1, L, R, Meter, the selected waveform, oscillator, LFO, Envelope, Controls, etc... Whenever a button is pushed (e.g. the oscillator or LFO or ENV selection button), the LCD should jump to the configuration page. This is an important test to ensure, that the CS is connected properly. Best Regards, Thorsten.

Since V4.071 we have a TRACK_CC function, which can to be configured in the MBSEQ_HW.V4 file See also: http://www.ucapps.de/midibox_seq_changelog.html Does it help? Best Regards, Thorsten.

Hallo Roman, Ja, diese Funktion gibt es unter dem Namen "radio buttons". Suche mal auf dieser Seite nach dem Stichwort "radio": http://www.ucapps.de/midibox_ng_manual_fs.html Gruss, Thorsten.

Du musst schon sagen, was Du bauen moechtest, nur so kann ich Dir eine konkrete Antwort geben. Gruss, Thorsten.

Yes, I could add dedicated buttons for SAVE (to store the pattern of the current group) and SAVE_ALL (to store the patterns of all groups). Best Regards, Thorsten.

Bei der MBNG kannst Du bis zu 8 DINX4 Module hintereinanderschalten. Aber was moechtest Du mit den Tastern eigentlich machen? So waere bspw. eine 16x16 Matrix geschickter (bis zu 256 Buttons) - fuer diese Matrix benoetigst Du lediglich ein MBHP_DIO_MATRIX Modul (siehe auch: http://www.ucapps.de/mbhp_dio_matrix.html ), sowie je eine 1N4148 Diode pro Taster. Ja, der integrierte Texteditor reicht aus, siehe auch: http://www.ucapps.de/midibox_ng_manual_fs.html Gruss, Thorsten.

With "fwd=BUTTON:500" you will forward a the value to the button, but this won't trigger a MIDI event. This is intended - e.g. let's assume the case, that you forward a value from a button to a LED - in this case you definitely don't want that the LED sends a second MIDI event. The usage of EVENT_SENDER should help here. Try this: Best Regards, Thorsten.

Respekt! Das Projekt bietet mit ueberschaubarer Hardware einen erstaunlich guten Sound! Gruss, Thorsten.

The problem with such a function: the save operation takes some time. Normally you don't notice this, because it's done in background. But if it would be done before the sequencer switches to a new pattern, it would stall the engine for several mS, which is not desired (but also not avoidable). In addition, I would have to overwork some routines, so that they flag changes. If the flag is not set (no changes in the pattern done), an autosave wouldn't be required (and this would avoid the unwanted stall) Best Regards, Thorsten.

MIDIbox NG waere die erste Wahl: http://www.ucapps.de/midibox_ng.html MIDIO128 die zweite Wahl (ist etwas einfacher zu konfigurieren, bietet jedoch weniger Funktionen): http://www.ucapps.de/midio128.html Gruss, Thorsten.

It's not really a voltage converter, but a logic chip which outputs 5V for digital-1, and accepts input voltages below 3.3V to reach this level. Btw.: I just got the idea that there would be another possibility: if you own a MIDI device with a MIDI Thru port, then just route the MIDI signal through this device. Means: MBSEQ V4L -> MIDI IN of your device (e.g. a synth) MIDI THRU of your device (the synth...) to MIDI IN of your drum machine. Background: a MIDI THRU port is usually buffered - and therefore would shift the voltage level as well -> no tinkering required ;-) Best Regards, Thorsten.

Thanks! I was able to reproduce the issue, and think that it was related to a MIDI OUT access conflict. The .NGR execution is protected with a MUTEX_MIDI_OUT now, and this seems to help. Could you please try the latest version in the repository at your side? Best Regards, Thorsten.

It's described here: http://www.ucapps.de/mios_studio.html Of course, you could create additional aliases with different arguments. Best Regards, Thorsten.

In order to ensure, that this isn't related to a Windows issue, could you please check the routing with a "known working" MIDI device? E.g. you could connect a synth to MIDI OUT2 and check if you can play notes from the virtual keyboard of MIOS Studio to the synth with: set router 1 USB2 all OUT2 all And you could check the MIDI IN by connecting MIDI OUT of the synth to MIDI IN2, and using following command: set router 2 IN2 all USB2 all (Note: now we are using the second USB port instead of the third...) Does this work? Best Regards, Thorsten.

Unfortunately I'm not familiar with Protools, and especially don't know if it supports fully customized control over channel strips. If this can't be directly configured in Protools itself, you could search for an existing hardware controller which already provides such a feature, and then we could help you to create a .NGC file which emulates the protocol. As long as an emulation (MIDI message translation) isn't required, you could route the IN/OUT ports of MBHP_MF_NG directly to protools as described above. Best Regards, Thorsten.

Do you mean with GM5 port, that you are working under Windows, installed the GM5 driver, and enabled the Single-USB option for your core module? Or do you access the MBHP_CORE_LPC17 module via a GM5 MIDI interface (so: MIOS Studio communicates via IN1 and OUT1)? Best Regards, Thorsten.

I started with some tutorials for MBSEQ V4 -> http://www.ucapps.de/midibox_seq_manual_tut.html More will follow from time to time... :) Best Regards, Thorsten.

This particular usecase is now described in the third tutorial: http://www.ucapps.de/midibox_seq_manual_tut3.html More tutorials will follow, and will be announced in the release thread: Best Regards, Thorsten.

Thanks, this was helpful! :) Found it, fixed it - please try this preliminary release: http://www.ucapps.de/mios32/midibox_ng_v1_025_pre5.zip It doesn't solve the cursor issue yet, because I've to think about the best suitable implementation for this extension. Best Regards, Thorsten.