TK.

see http://www.ebay.de/itm/171931571912 R: 500-800mcd, G: 3000-5000mcd, B:2000-3000mcd 220 Ohm for R+G, 100 Ohm for B Hm! How could I overlook this! Actually I intended to try out this chip some months ago, but I totally forgot about this possibility! :) The SPI usage would be too expensive for this purpose, especially since most MBHP_CORE_* modules only have 3 integrated SPIs which are already assigned to other peripherals. But a 800bps rate (output only) can be easily achieved via bitbanging, e.g. if a DMA transfers the prepared pin access patterns triggered by a timer. I will try this soon, because it will be a much better solution for RGB LEDs! E.g. this seems to be a nice one: http://www.ebay.de/itm/1m-60-RGB-LED-Strip-schwarz-mit-WS2812B-5050-SMD-LEDs-WS2811-Controller-WS2812-/371332277097?hash=item567520e369 Best Regards, Thorsten.

Unfortunately you won't be able to detect a defect in the 74HC14 with an ohmmeter. The 74HC14 is an inverter chip, if input 6A is at logic-0 level (around 0V), 6Y should be logic-1 (around 5V) and vice versa. If this isn't the case, lift 6Y (pin 12) - means, put this pin out of the socket - and measure again. If you still don't notice the inverting function, then the chip is defective and needs to be replaced. Of course, overvoltage or wrong polarity could destroy this chip very quickly. The MBHP_BURNER project is maybe not the best one for beginners. Actually today (10 years later) I would recommend to buy a cheap PICkit2 (clone) at Ebay instead. See also http://www.ucapps.de/mios_bootstrap_experts.html So - if you are not able to get MBHP_BURNER running, consider to buy a PICkit2 at Ebay, it will be less troublesome. Best Regards, Thorsten.

Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre16.zip The new command can be called with: exec_meta SaveDelayedSnapshot:15 this will store the snapshot after at least 15 seconds (if there is no ongoing request) Currently it doesn't check if any value has been changed - this will become a difficult task at my side, but let's see if this command is already sufficient. Btw.: with "set debug on" in the MIOS terminal you will get a notification message whenever the snapshot save operation takes place. Best Regards, Thorsten.

An event only takes place on a value change, but the problem is that with DumpSnapshot you provoke that all values will be sent out (again). Btw.: is it clear to you, that DumpSnapshot doesn't store values, but sends the values of all control elements? SaveSnapshot would be the right command for this purpose, but the problem is, that it store immediately with the effect that if the section is called rapidly multiple times per second (for whatever reason), the store operation will stall MBNG too much. I think the only proper solution for your use case would be a new NGR command which requests a snapshot save, and only if any value has been changed - it shouldn't take place more often than once per second, right? Best Regards, Thorsten.

All that legato/sustain/note stretch features have been removed from the firmware (which is originated from MBSEQ V3) and no memory has been reserved to store such a parameter, therefore I don't see a way to consider your request. So, if you find a different solution (e.g. firmware change in 9090) it would be better. However, if you've luck following MB808 firmware change could already help: in src/seq_layer.inc, search for SEQ_LAYER_GetEvntL, it's currently: SEQ_LAYER_GetEvntL movlw 0x10 ; fixed length movwf SEQ_EVNTL, BANKEDIf you change it to: SEQ_LAYER_GetEvntL movlw 23 ; fixed length movwf SEQ_EVNTL, BANKEDthe note length should be almost 1/16th Higher values could result into legato, but I haven't tested this... Btw.: which firmware version are you using? V1.4 got some new features, e.g. a HH control switch for 909: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_808%2FCHANGELOG.txt But I noticed that I haven't officially released it yet; the mios_download page still shows v1.3 Best Regards, Thorsten.

The sammichFM is maybe a bad example, because the user interface doesn't allow to select the pages directly (like for example a MIDIBox SID (not sammichSID). However, it makes sense to collect opinions from future users. It should be possible to implement different CS approaches for the same hardware, just the frontpanel silkscreen will be different. Best Regards, Thorsten.

Hi Andy, why do you want to dump the values from this section? Is this really necessary? Best Regards, Thorsten.

I checked this today: http://midibox.org/forums/topic/19752-rgb-hue-sweep/ For LED Rings I fear that there are not enough brightness levels, e.g. even with a 8x4 configuration there are effectively only 4..5 different levels! Best Regards, Thorsten.

Results: http://midibox.org/forums/topic/19752-rgb-hue-sweep/

Today I did some experiments with RGB LEDs, e.g. to evaluate Andy's idea to use a single RGB LED as replacement for LED rings around encoders: http://midibox.org/forums/topic/19619-alternative-to-led-encoder-rings-illuminated-red-green-encoders/ Outcome: a LED matrix configuration doesn't give us enough brightness levels. E.g. I tried a 4x8 matrix which allows 8 brightness levels for each color, but it turned out that dim values above 4 (50%) don't make a big difference anymore, accordingly the actual resolution was only 2 bit (4 brightness levels)therefore I connected the R/G/B LEDs directly to DOUT pins, which gives us up to 16 dim levels and higher brightness (since no multiplexing takes place). Results where much better!In order to generate different hues, I use the HSV color model, and sweep H from 256..0 and V from 0..100% (S always 100%) See http://colorizer.org for the resulting colors Script: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Ftools%2Fgen_colour_maps.plThe generated R/G/B Maps are then used in a .NGC file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frgb_4.ngc This example configuration shows, how the RGB hue can be controlled from a single encoder (or via incoming CC event)Conclusion: if LED rings should be replaced by RGB LEDs, we need 3 dedicated DOUT pins per LED, makes 48 pins for 16 RGB LEDs = 6 DOUT SRs Line drivers are not required, since the DOUT SRs are strong enough to drive the LEDs. Best Regards, Thorsten.

Whenever the LFOx or ENVx depth is changed, or the LFO1/LFO2/ENV1/ENV2 button is pushed, the appr. menu page will be selected which then allows to edit the remaining parameters. If somebody prefers to control a certain parameter directly, e.g. LFOx rate or ENVx decay, he has to change the encoder assignments. I think that at the end we might be able to use the same frontpanel, but labels need to be customized based on personal preferences. Best Regards, Thorsten.

This kind of enumeration is legacy (e.g. same is used in MBSID and MBFM), please don't enforce a change (I won't do it anyhow ;-) Whenever a value is changed, the related CV1..8 channel + the parameter name is print on screen. No need to think about a different approach. this won't work in live situations, where you want to have immediate access to parameter splitted over different channels Your idea actually goes into a direction from where I wanted to get rid of. The purpose of the 4x4 encoder field shouldn't be to replicate that what can already be configured with the menu interface. Instead they should give you direct access to all parameters that you want to tweak live while playing sounds w/o switching banks or channels. Actually the firmware is constructed for 8 voices which work independent from each other. The idea is to customize the access to voice parameters in order to simplify the usage - the frontpanel design should consider this. I think the biggest problem is, that you want to customize your MBCV for 8 voice usage and quick access to all configuration parameters. And that I'm looking for something different, tailored around my own use case. I fear that I've to create an alternative frontpanel design for my own usecase... :-/ That's ok, but the second layer which allows to change SEQ configuration parameters isn't necessary. It's much easier to change these parameters from the menu interface, nobody will use the 4x4 encoder field for this purpose. Best Regards, Thorsten.

The MB808 firmware doesn't allow to configure the gate length of analog triggers, the pulse length is 1 mS for all outputs, and it won't be so easy to change with the existing code basis. I'm surprised that we haven't noticed this issue with the 808 modules, could it be that monoflops are missing for the drums which need to be played over long time? E.g. I found this blog via google: http://niroke.blogspot.de/2015/04/trigger-in-mod-for-tr-9090.html Are you using such a mod, or how did you connect the triggers? Best Regards, Thorsten.

Please note: LFOA, LFOB, ENVA, ENVB, MODA..D are actually called LFO1, LFO2, ENV1, ENV2, MOD1..4, please change the graphics accordingly to avoid confusion. From my point of view, the encoder assignments are too much channel-related. I would prefer the configuration 2(VCO, VCA, VCF, MOD; Gate, Trig, Retrig, /Trig) with encoder assignments which change the most important parameters of an "instrument", such as: CV1: VCO1 PitchCV2: VCA1 AmplitudeCV3: VCF1 CutOffCV4: Aux1CV5: VCO2 PitchCV6: VCA2 AmplitudeCV7: VCF2 CutOffCV8: Aux2 And the default encoder assignments could be:ENC1: CV1 OctaveENC2: CV1 SemitoneENC3: CV1 FinetuneENC4: CV1 PortamentoENC5: CV2 LFO1 DepthENC6: CV2 LFO2 DepthENC7: CV2 ENV1 DepthENC8: CV2 ENV2 DepthENC9: CV3 LFO1 DepthENC10: CV3 LFO2 DepthENC11: CV3 ENV1 DepthENC12: CV3 ENV2 DepthENC13: CV3 Value (Changes Octave/Semitone/Finetune)ENC14: CV4 Value (Changes Octave/Semitone/Finetune)ENC15: CV4 MOD1 DepthENC16: CV4 MOD2 Depth I don't see the need to configure the MOD parameters with the 4x4 encoder matrix, it's much easier to change them from the appr. configuration page. Same for the ARP and SEQ configuration. Best Regards, Thorsten.

I've to doublecheck: you wrote that the Vdd LED can be switched on/off from the P18 software. This LED gets it's logic status (on/off) from pin 12 But now you are writing that there is no voltage, neither at pin 12 nor at 13 So: what changed meanwhile? Best Regards, Thorsten.

The router settings should be automatically saved when you exit the page. E.g. just press the EXIT button or change to another page (EDIT button or whatever) It can be explicitly saved with the SAVE function in the main menu (GP button 10) Best Regards, Thorsten.

LEDs can be dimmed with the set_rgb command in the .NGR script; however, the resolution depends on the matrix configuration; with 8 rows we've only 4 dim levels anymore. How many dim levels has the 4x4 encoder box? Best Regards, Thorsten.

Instead of if BUTTON:1001 == 0 set LED:23 0 set LED:22 0 set LED:21 0 else if BUTTON:1002 == 25 set LED:23 127 set LED:22 0 set LED:21 0 else if BUTTON:1003 == 51 ...you could also write: if BUTTON:1001 == 0 set LED:23 0 set LED:22 0 set LED:21 0 elseif BUTTON:1002 == 25 set LED:23 127 set LED:22 0 set LED:21 0 elseif BUTTON:1003 == 51 ... endifthis results into a (little bit) faster handling, and is also easier to read & update The .NGR script will be executed in one go after the snapshot has been loaded. I haven't mentioned it yet, but it could make sense to set the "no_dump=1" parameter for all events which get their value from other events via fwd_id This avoids unnecessary repetition. Note that after the modification you've to store the snapshot once in order to remove the unnecessary values. Thereafter a restore should work faster. Best Regards, Thorsten.

1k is fine Best Regards, Thorsten.

Cheers! :) Best Regards, Thorsten.

Please wait for this until I've checked various RGB LEDs at my side (it's on my Agenda to try this out for upcoming MBCV V2) I've already the RGB LEDs, just need some time for some experiments - and I will try this with a MBNG. It might be that I will add special extensions to minimize wiring effort, but to ensure that we've enough dim levels Best Regards, Thorsten.

This won't work, because this way you will create a non-linear resistor network. There is no solution to turn a 50k fader into lower resistances, the high fader resistance is prone to jitter Best Regards, Thorsten.

Very well done! Value forwarding can be disabled with a conditional event, e.g.: EVENT_CV id=1 if_equal LED:1:0 ...will only change CV:1 if the value of LED:1 is 0 For driving a second DOUT you could forward in a chain: EVENT_BUTTON id=1 fwd_id=LED:1 ... EVENT_LED id=1 fwd_id=LED:2 ... EVENT_LED id=2 ...BUTTON:1 forwards to LED:1, and LED:1 forwards to LED:2 But for the case that you would like to restore the original CV value if LED:2 changes back from any value to 0 (unmute), you finally need a .NGR script which is triggered by an EVENT_SENDER: EVENT_BUTTON id=1 fwd_id=LED:1 ... EVENT_LED id=1 fwd_id=SENDER:1 ... EVENT_SENDER id=1 type=Meta meta=RunSection:1And in the .NGR script something like: if ^section == 1 if BUTTON:1 == 0 # button depressed: unmute set LED:2 0 # copy current AINSER:1 value to CV:1 set CV:1 AINSER:1 else # button pressed: mute set LED:2 127 # mute CV output set CV:1 0 endif endif Best Regards, Thorsten.

Actually I missed to add this to the UTILITY page. Please try this pre-release: http://www.ucapps.de/mios32/midibox_seq_v4_090_pre1.zip It comes with another new feature: the right half of the Fx->Scale screen shows the resulting keys now, which should help to get an overview about the forced notes which will be played. Best Regards, Thorsten.

Ok, I tried following minimized configuration: MAP1 1 2 3 EVENT_BUTTON id=1 fwd_id=SENDER:1 range=map1 button_mode=Toggle EVENT_SENDER id=1 type=NoteOn chn=1 key=0x4b EVENT_BUTTON id=2 fwd_id=SENDER:2 button_mode=OnOnly EVENT_SENDER id=2 fwd_id=BUTTON:1:1and found a way to handle your use case. Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre15.zip Best Regards, Thorsten.