Project: MiniMoog Voyager Style Midi Synth

[Highcooley]

After over a year of development, I would like to start documenting my Midibox_NG project in this thread to collect as much information as possible for similar future projects. The idea is to keep all findings, questions and struggles concerning this projects in one thread to keep myself organised and to help future digital/analog synth developers.

As the title predicts, the goal of this project is to design and develop an all in one box digitised analog synth, similar to the MiniMoog Voyager. The synth will be controlled solely over midi. An LPC17 with Midibox_NG running acts as the main brain to read digital pots and switches of the control panel, save and recall presets as well as to drive the synth through multiple analog and digital outputs.

Analog synth hardware:
1x LFO
2x Modulation Bus
3x VCO incl. waveshapers as well as additional loops for other effects than the waveshapers (documented on: http://www.muffwiggler.com/forum/viewtopic.php?t=108794)
1x Noise generator
1x Ext_In
1x Mixer stage
1x 5Pulser (http://home.comcast.net/~ijfritz/sy_cir8.htm)
1x Ring modulator
1x Phaser effect
2x Moog ladder LP filter (to create a stereo effect through filter cutoff spacing)
1x Moog T904B HP filter (to create a band pass together with one of the LP filters (http://www.freeinfosociety.com/electronics/schemview.php?id=944)
2x ADSR (for filter and volume)
1x Stereo VCA
1x Headphone preamp
1x +/-15V & +5V switching power supply (I learned, that it is much easier to develop circuits with the additional "headroom" of +/-3V in comparison to a +/-12V supply)
1x Power board to generate +/-12V for the AOUT_NG modules as well as +10V clean reference voltage.

 

Resources
All the analog circuits are redesigned and relayouted to be uC controllable. They are mainly based on the following modules:
- Ninni Bergfors' Moog based bergfotron modules (http://hem.bredband.net/bersyn/)
- Original Moog D schematics (http://www.fantasyjackpalance.com/fjp/sound/synth/synthdata/16-moog-minimoog.html)
- Original Micromoog schematics (http://www.fantasyjackpalance.com/fjp/sound/synth/synthdata/07-moog-micromoog.html)

- Yves Usson's Yusynth (http://yusynth.net/Modular/index_en.html)
- René Schmitz's modules (http://www.schmitzbits.de/)
- Carsten Toensmann's Moog Modular Clone (http://www.analog-monster.de/mmschemos.html)

- Vinnui's Modbus concept (http://vinnui.blogspot.ch/2011/09/concept-of-modulation-bus.html)

The original idea was to use the Moog D schematics solely and as many original parts as possible. But after already acquiring many old parts for a reasonable amount of money, I dumped the idea when the last Chinese seller of UA726 remakes went off market. However, I don't regret the decision, as I am very happy with my results so far with more modern parts, which are not nearly as energy hungry as the old stuff.

Midibox Hardware:
1x LPC17 core module
1x KS0108 based graphic LCD
1x SD card reader
1x AINSER64 module
1x DIO_MATRIX module
1x DOUT module (own design with partly high power shift registers for switching relays)
4x AOUT_NG modules

Development Roadmap (fully implemented, partly done, not touched yet):
- HARDWARE Power Board
- HARDWARE Midibox modules (excl. DOUT)
- HARDWARE VCO & waveshaper board (incl. trimming & tuning)
- HARDWARE LP filter 
- HARDWARE HP filter & filter switching circuit
- HARDWARE 5Pulser
- HARDWARE Ring Modulator (on the breadboard and PCB layouted)
- HARDWARE ADSR (PCB layouted)
- HARDWARE DOUT module
- HARDWARE control panel pots & switches 
- HARDWARE Mixer including overdrive LED circuit
- HARDWARE VCA & headphone preamp
- HARDWARE LFO, MOD BUS, Noise generator circuits and PCB
- HARDWARE Casing
- HARDWARE Phaser (planned as a seperate module, since not enough AOUTS available)

- SOFTWARE Utilising AINSER64 and AOUT_NG at one port ()
- SOFTWARE Controlling multiple AOUT_NG modules at once ()
- SOFTWARE VCO octave switch option (thanks TK)
- SOFTWARE Multiple rotary switches locking each other out (softwarebug ironed out, thanks again, TK)
- SOFTWARE Controlling Digital switching ICs (binary input) by DOUTs (signal switching related topic)
- SOFTWARE synth fine tuningrange (+/- 3 semitones, steps as fine as possible) -> solved in the analog section, without midibox assistance

- SOFTWARE VCO detuning -> semitone detuning works, free detuning not implemented in MBNG)

- SOFTWARE Midibox_NG menu structure -> initial work done
- SOFTWARE Preset save and recall
- SOFTWARE Midi control of parameters (excl. tone & pitch bend)

Edited February 14, 2017 by Highcooley
frontpanel elements complete

[Highcooley]

Strange DIO_MATRIX rotary switch problem:

 

On the front panel, I use 9 rotary switches to select stuff like octave, modulation routing, etc. The cabling is done like the typical scan matrix application for DIO_matrix modules (http://www.ucapps.de/midio128/midio128_v3_dio_scanmatrix.pdf). I connected the multiple switch positions of my first rotary switch to C0-C7 and the slider via a diode to R0. The second switch is connected to C0-C7 and R1, and so on, and so forth. Unlike momentary switches, one position of each rotary switch is always ON, of course. 

 

When I switch on the midibox initially, usually I am able to select each position on each switch as desired. But somehow, after a while/a couple of times switching/operating several different switches/many switches in the same position (not sure yet, what causes the new behavior), I can suddenly not select the same position as a certain other switch has anymore.

 

E.g. switch A is in position 2 and I operate switch B. The LCD display shows each change of switch B reliably. But suddenly, when I try to put switch B to position 2 (again), the display shows, that I have put switch A to position 2 instead. I am then not able to put switch B to position 2 anymore, until I change switch A to position 3 for example. But now, position 3 of switch B is locked until I change the position of switch A again.

 

Does anybody have an idea, what could cause this interlocking situation? As I don't know, how the DIO_matrix's scanning pattern works, it is hard for me to figure out what could cause this behavior. I can only guess that it could be a problem related to:

- cable length leading to some kind of interference problem (I have one 20 cm flat ribbon cable from the module to a distribution node and lengths from there to the switches between 10-30 cm)

- some kind of saturation problem (because it is occurring over time) 

- depending on the scan pattern, too many switches in the same position causing unwanted voltage drops

 

I might be able to shorten the cable from the module to the node a little bit, but that won't help on the maximum length that much. Another thing to try would be to completely reverse how the rotary switches are connected and go from C0 via diode to the slider and connect the different positions to R0-R7.

 

Before I start messing up the nice cabling and spend another 5 m of new cables and hours of my time, I would like to hear your opinion on this. Has anybody experienced similar problems? 

[jrp]

Very interesting project! Seems like you have already come a long way.

I was only briefly reading across the post on the other forum.

Are you blending from saw to tri, or are you actually altering the slope of the signal (like pwm for triange: "very fast ramp up, slow ramp down" to "medium ramp up and down" to " slow ramp up, very fast ramp down)?

I couldn´t really make that out on the scope shots. My circuit unfortunately only acts as a blend from one wave to the other, doesn´t sound as cool, but still very nice.

 

Quite some time ago i built a similar waveshaper and i would like to share some of the findings i had.

If i understand correctly you are having trouble with volume compensation (?) while morphing through the waveshapes.

 

 

What i did:

 

- Use the saw to tri converter of a common VCO design (ray willson) and put it under voltage controll. (The trimmer in these circuits alrady acts as a variable voltage source to blend from saw to tri, so it´s quite simple). Signal was simply ac coupled afterwards if i remember correctly, maybe i also used the very same cv to provide an variable offset, balancing the signal around 0v.

 

- Used the sineshaper of the same design, but with a vca before it. This allows to blend form tri to square with a second CV. The first CV will then act as a PWM controll.

 

- I compensated the volume changes using a simple optical limiter circuit in feedback configuration. Instant attack, release tuned for minimum distortion at low frequ.

  I think i went through the trouble of precission full wave rectifying the signal first, then integrating and controlling the brightness of an LED. LDR is in the feedback of the output driver.

Nowadays i would propably use a vca instead, but on the other hand, the optical cell worked very well. It´s a lot of trimmers though... but it holds the signal at 10vpp very nicely

 

Sorry i never did any schematics....

[Highcooley]

Thanks a lot for your insights in your project! 

 

As it seems, I took a very similar approach to your solution.

 

- I actually do exactly the same, voltage controlling a common saw to tri converter to do this kind of transition. And that's where I had the first problem, compensating the voltage level from cutting the saw signal to half and also balancing it around 0V. I solved this with the first LM13700 only being affected during saw-tri transition.

 

- However, I didn't AC couple the signal between tri-saw and saw-rect to keep the distortion as low as possible. As a result, the signal at the output before the AC coupling moves from -10/0 to 0/+10, limiting the different trimming ranges due to the DC component of the signal.

 

- I wanted to use only one CV to blend through all the different wave shapes. Therefore I split the CV, using the lower half (0-5V) for the tri-saw transition and the upper half (5-10V) to transit from saw to rect as well as subsequently modulate the pulse width of the rectangle. The pulse width modulation is only done with the rectangle and not with the triangle signal.

 

- Your solution with the sine converter to get a rectangle sounds pretty neat. I copied the circuit used in the micromoog, which uses a variable threshold to clamp the signal to a positive DC level above the triangle AC signal level. This leads to an instant doubling of the pp voltage. It's not that critical for the signal volume however, since the average volume does not change that much.

 

- The LDR approach is probably very precise, since the average signal volume changes a lot during transition. I managed to get pretty much the same pp values for the three clean mayor signals saw, tri and rect. Of course, the over all volume changes during the tri-rect transition and again during rect PWM. But I'm still happy with the result.

 

By the way, the documentation on the muffwiggler forum is not yet finished. Meanwhile, I have the circuit refined, the PCB edged three times and all three VCO's are working very well together after a lot of tweaking the circuits. I am going to document the final circuit as well as all the findings soon.

[jrp]

Did you really experiance audible distortion when AC coupling the signal? Should be very doable with a low enough Lowcut around 5Hz. Eg 330nf into a 100k load.

 

Using a sineshaper is in fact nice as you can morph from tri to sine to square, or from saw to rounded saw to pulse.

I found this sounds even more useful compared to the tri to saw fading as it provides a nice range of morphing overtones, really altering the spectrum (compared to just fading in the upper overtones with a tri to saw fade.

Of course the fading from tri to saw is nice as well! What would be cool: real morphing of the up and down portion of the ramps at a given frequency. Seems like this is rather a complex task in an analog circuit though... Some digital synths do it, sounds very nice.

[Highcooley]

Did you really experiance audible distortion when AC coupling the signal? Should be very doable with a low enough Lowcut around 5Hz. Eg 330nf into a 100k load.

 

Using a sineshaper is in fact nice as you can morph from tri to sine to square, or from saw to rounded saw to pulse.

I found this sounds even more useful compared to the tri to saw fading as it provides a nice range of morphing overtones, really altering the spectrum (compared to just fading in the upper overtones with a tri to saw fade.

Of course the fading from tri to saw is nice as well! What would be cool: real morphing of the up and down portion of the ramps at a given frequency. Seems like this is rather a complex task in an analog circuit though... Some digital synths do it, sounds very nice.

To be honest, I never checked how much distortion an additional AC coupling would cause. I went for the classic 10k, 10uF and noticed that the sharp edges of the sawtooth and traingle get rounded a bit on the scope. That's when I decided not to do any more AC coupling on the VCO.

 

You're right, real morphing would be very nice. However, controlling the upper and lower portion gets more complex and as you say, is also a bit more complex to realise with analog circuits. Ian Fritz has two nice approaches with the "Wavolver" and the "SNICster": http://home.comcast.net/~ijfritz/sy_over.htm

 

Hmm, you also don't have any idea what I could try to solve the DIO_matrix rotary switch problem?

[Highcooley]

After a longer pause, the project is moving on. Find the documentation and schematics of my VCO, waveshaper & VCM design here:

https://www.muffwiggler.com/forum/viewtopic.php?p=1856429#1856429

 

The PCBs of the LP part of my VCF are ordered and the HP portion is in design.

[Highcooley]

Hey everybody. After some hot summerholidays it is time to work on my synth again.

Meanwhile, all the PCBs (except for the modbus/ DOUT board which still has to be designed) have arrived and are ready to be populated. [photos comming soon]

The 5Pulser and Ringmod board worked on the first try after the soldering was complete. It was still a lot of work cabling and tuning everything, but it all worked straight away which is seldom the case in my electronics experience.

I also just finished assembling, tuning and debugging the filter stage. This was a lot more work as the circuits are a lot more complex and have to work unisono. It is now possible to switch between using the two LP filters in parallel to generate a Stereo effect by phase shifting one filter or using one LP filter sequentially with the HP filter generating a bandpass and also phase shifting the HP filter to widen the band.

By using, switching and shifting I mean doing it manually, since these modules are not yet connected to the midibox controller. The analog part should be easy, as I configured everything already when I did the VCO stages. However, I haven't tackled DOUT to switch relays as well as toggle LED buttons on the DIO MATRIX side yet. And since I haven't done a lot of midibox programming/ configuration work lately, it will be a challenge again to get everythong hoocked up properly.

Next will be the ADSR and VCA circuits. The boards are populated and ready for testing.

Edited August 31, 2015 by Highcooley

[Highcooley]

The project is continuously growing. Thanks to TK, 4 AOUT_NG modules are working splendid now and he also helped by ironing out a software bug in the AINSER_NG module which caused problem in conjuncture with the DIO Matrix scan algorithm: http://midibox.org/forums/topic/19709-dio-matrix-going-haywire/

I finished all the front panel LED buttons, including the SCS:

 

Next up will be the LFO/Mod Bus/Noise Source circuit board on the hardware side and figuring out how to use a button to override a AINSER to AOUT value in order to mute a channel. No idea how this is being done. I guess it can be solved with SENDERs and RECEIVERs. In general, if someone knows how I can light an LED as well as set a separate DOUT pin with one button press, I would highly appreciate some help.

I am looking forward to post some audio samples or video of the synth working soon.

Regards,

Andy

 

Edited October 5, 2015 by Highcooley
Added Picture

[TK.]

Very well done! 

Next up will be the LFO/Mod Bus/Noise Source circuit board on the hardware side and figuring out how to use a button to override a AINSER to AOUT value in order to mute a channel. No idea how this is being done. I guess it can be solved with SENDERs and RECEIVERs. In general, if someone knows how I can light an LED as well as set a separate DOUT pin with one button press, I would highly appreciate some help.

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:1

And 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.

[Highcooley]

Splendid, this method works great! I slowly start to understand how .NGCs and .NGRs can be used.

EVENT_CV id=1 if_equal LED:1:0 ...

I believe it should be with an "=":

EVENT_CV id=1 if_equal=LED:1:0

 

To understand exactly what is happening here (I actually don't use the buttons as mute but as activate now, hence 127 and not 0):

#NGC
EVENT_LED id=2041 fwd_id=SENDER:3006
EVENT_LED id=2042 fwd_id=SENDER:3006
EVENT_LED id=2043 fwd_id=SENDER:3006
EVENT_LED id=2044 fwd_id=SENDER:3006
EVENT_LED id=2045 fwd_id=SENDER:3006
EVENT_SENDER id=3006 type=Meta meta=RunSection:1

#NGR
if ^section == 1
	if BUTTON:1081 == 127
		set CV:11 AINSER:17
	else
		set CV:11 0
	endif
	
	if BUTTON:1082 == 127
		set CV:12 AINSER:18
	else
		set CV:12 0
	endif  
	
 	if BUTTON:1083 == 127
		set CV:13 AINSER:19
	else
		set CV:13 0
	endif 

	if BUTTON:1084 == 127
		set CV:14 AINSER:20
	else
		set CV:14 0
	endif	

	if BUTTON:1085 == 127
		set CV:15 AINSER:21
	else
		set CV:15 0
	endif
endif

As soon as any of the five LEDs changes, the .NGR script should be executed once. Is this correct? I tried to add a dump Snapshot to the end of the NGR script to save changes, so I can automatically load the same toggle button state again after reset. But if I do, I can hear a short interruption at my audio out about every second which tells me that this dump is being done repeatedly, interrupting the processor.

 

Another question in regards of .NGRs: I want to address a digital switching IC (CD4051) binary, using DOUTs. I do have a rotary switch configured as a radio group. So that's how the configuration looks like (I nested the if statements to save processing time):

#NGC
EVENT_BUTTON id=  1001  type=CC    button_mode=OnOnly chn= 1 CC= 68  range=   0:0   radio_group=1   fwd_id=SENDER:3007  lcd_pos=1:1:4  label="MW Source  Tri       "
EVENT_BUTTON id=  1002  type=CC    button_mode=OnOnly chn= 1 CC= 68  range=  25:25  radio_group=1   fwd_id=SENDER:3007  lcd_pos=1:1:4  label="MW Source  Square    "
EVENT_BUTTON id=  1003  type=CC    button_mode=OnOnly chn= 1 CC= 68  range=  51:51  radio_group=1   fwd_id=SENDER:3007  lcd_pos=1:1:4  label="MW Source  OSC 3     "
EVENT_BUTTON id=  1004  type=CC    button_mode=OnOnly chn= 1 CC= 68  range=  76:76  radio_group=1   fwd_id=SENDER:3007  lcd_pos=1:1:4  label="MW Source  S&H       "
EVENT_BUTTON id=  1005  type=CC    button_mode=OnOnly chn= 1 CC= 68  range= 102:102 radio_group=1   fwd_id=SENDER:3007  lcd_pos=1:1:4  label="MW Source  ON/MOD2   "
EVENT_BUTTON id=  1006  type=CC    button_mode=OnOnly chn= 1 CC= 68  range= 127:127 radio_group=1   fwd_id=SENDER:3007  lcd_pos=1:1:4  label="MW Source  Noise/PGM "

EVENT_RECEIVER id=3007 type=CC chn=1 cc=68 fwd_id=SENDER:3007
EVENT_SENDER   id=3007 type=Meta meta=RunSection:2

#NGR
if ^section == 2
    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
                set LED:23 0
                set LED:22 127
                set LED:21 0
            else
                if BUTTON:1004 == 76
                    set LED:23 127
                    set LED:22 127
                    set LED:21 0
                else
                    if BUTTON:1005 == 102
                        set LED:23 0
                        set LED:22 0
                        set LED:21 127
                    else
                        if BUTTON:1006 == 127
                            set LED:23 127
                            set LED:22 0
                            set LED:21 127
                        endif
                    endif
                endif
            endif
        endif
    endif
endif

If I do it this way, are the three LEDs being switched sequentially causing unwanted states or are the .NGR operations being executed all in one go before the serial update?

 

Thanks once more for your help. I hope this conversation is not only beneficial for my project but also for other people.

 

Regards,

Andy

 

Edited October 10, 2015 by Highcooley

[TK.]

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
    ...
    endif

this 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.

But if I do, I can hear a short interruption at my audio out about every second which tells me that this dump is being done repeatedly, interrupting the processor.

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. 

[Highcooley]

Thanks Thorsten

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

I did both, the elseif change as well as the nodump for all forwarded events (mostly senders anda  couple of LEDs). Now if I have the DumpSnapshot command in section 1, I do have the short interrupt faster than every second, but it is still audible:

#NGC
EVENT_BUTTON id=  1081  type=CC    fwd_id=LED:2041  button_mode=Toggle  chn= 1 cc= 81  range=   0:127
EVENT_BUTTON ...

EVENT_LED id=2041 fwd_id=SENDER:3006
EVENT_LED id=2042 fwd_id=SENDER:3006
EVENT_LED id=2043 fwd_id=SENDER:3006
EVENT_LED id=2044 fwd_id=SENDER:3006
EVENT_LED id=2045 fwd_id=SENDER:3006
EVENT_SENDER id=3006 type=Meta meta=RunSection:1

#NGR
if ^section == 1
	#Mixer Channel activation
	if BUTTON:1081 == 127
		set CV:11 AINSER:17
	else
		set CV:11 0
	endif

    if BUTTON...
      ...
    endif
	
	# Safe current button states not working
	exec_meta DumpSnapshot
endif

So, section 1 gets executed each pass as long as at least one button/LED is on. Each time, the settings get dumped and the signal interruption happens because of the access time to the SD card. Is there a way to only do a snapshot dump if any of the button events changed since the last pass?

 

Best Regards,

Andy

[TK.]

Hi Andy,

why do you want to dump the values from this section? Is this really necessary?

Best Regards, Thorsten.

 

[Highcooley]

Hi Thorsten

Hi Andy,

why do you want to dump the values from this section? Is this really necessary?

Best Regards, Thorsten.

 

It hasn't necessarily to be this section. I just want to automatically recall all last toggle button states after each power on. And since I don't see a way, how they could be saved when the power gets switched off, they probably have to be saved every time a button changes its state. I misunderstood the way the LED event works, since I thought it only would get executed once every time it changes its state. But obviously, this happens every time as long as the LED is lit. So this section is probably not the right one to do this dump. But how else can this be done?

Best Regards,

Andy

[TK.]

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.

 

[Highcooley]

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.

 

Hmmm, nope I was not aware of that. This explains some of the odd behavior I noticed. 

Is

exec_meta SaveSnapshot

implemented? I only get error messages if I have it in an .NGR

An .NGR command which only saves if there are changes and also doesn't save more often than every couple of seconds would be very elegant. I won't push a button and switch the synth off immediately afterwards anyways. So only saving if there are changes after 10-15 seconds would be more than enough.

Best Regards, Andy

[TK.]

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.

[Highcooley]

Hi Thorsten

Perfect, this command is splendid.

 

Best Regards,

Andy

[TK.]

cool! :)

Best Regards, Thorsten.

[Highcooley]

It is finally done, my Midibox NG powered analog synth hardware is finished. Usually, it runs pretty smooth with some occasional hiccups. Unfortunately, the power supply is off by almost half a volt on the +15V rail, so I have to re-tune everything. So, there is still some work to do. The next step will be to finish the software by figuring out a lot of stuff like an individual menu structure, free detuning of my second and third oscillator as well as preset save and recall and sending presets from and to the midibox by sysex. 

Thank you all very much for your support! I would never have come this far without the help of many passionate synth builders and midiboxers. I'd love to also post some samples. But since our first baby is due in the next couple of days, I can't promise much for the next days, weeks or even months. But stay tuned. I promise, some sound will eventually get posted. Until then, enjoy your hobby and see you soon :-)

 

 

[mongrol]

You Sir, are full of awesome and win.

[FantomXR]

Great build!! Have a good time with your family!