Jump to content

Highcooley

Members
  • Posts

    95
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Highcooley

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

    _4276940_komprimiert.thumb.jpg.aa0ae1016_4276942_komprimiert.thumb.jpg.b0d9c4271_4276943_komprimiert.thumb.jpg.74483ac0c_4276944_komprimiert.thumb.jpg.923403005_4276945komprimiert.thumb.jpg.711fb3ca7a_4276946_komprimiert.thumb.jpg.f11da5941

     

     

    • Like 1
  2. Just a quick followup:

    It was indeed a fried pin. After replacing the LPCxPresso board (Rev D) and going through the horror of figuring out how to get the bootloader onto that darn thing (as well as bending all of the header pins on the right side of the board in order to finally ram the displaced row into the headers of the midibox board), my LCD went back to operate perfectly.

    In case you need to set up a Rev D LPC17 as well one day, better find this post instead of figuring out the steps by yourself:

     

  3. :cheers: after a couple of hours going exactly through these steps myself, tripping over exactly the same stumbling blocks and figuring out exactly the same solutions, I find your post ...face palming myself. :rolleyes: But at least I can confirm, that it indeed works after a lot of pin bending and ramming the board onto the headers. I also soldered a short wire for the two Ethernet LEDs onto the left side of LED3 and 4. The network connector ones lit up, but only dimly. I guess, I should have done that either onto the right side of the SMD LED's or onto the left side of the corresponding resistors on the LPCxPresso board. But here is how I did it:

    LPC1769_RevD_ETH_LEDs.thumb.png.2fc2099f

     

    By the way, that's how the headers had to be bent in order to be able to give them a firm push to fit them onto the headers:

    IMG_2902.thumb.JPG.5115422cd186d29dc7b45

     

    ...and I can confirm that the Rev D board actually works with all the midibox bells an whistles (I'm using it with DIO, AIO, SCS, standard 2xmidi IO, USB, Ethernet and a single GLCD).

  4. Thank you for the compliment as well as your sympathies for the SEQ. Rest assured, the SEQ is all fine and dandy. It is my second project (a full fledged analog synth, based on Midibox NG) I am talking about, which also got a nice looking case. Pictures will follow, as soon as I get the display running.

    In my case, the two J5s as well as the J4s would be unused, as I'm running a SCS at J10. 

    Also thank you for pointing me into the right direction with the pin mapping file. It is not very appealing to build own explicit hex files of course. Especially, since I am more the hardware guy than the software specialist. But as a last resort, I am definitely looking into that. 

     

    Concerning the new LPC board, Embedded Artists state, that:

    Quote

    the expansion pins (2x27 positions) are mechanically compatible with the original design

    If I compare the schematics, the pinout is also exactly the same. There is only an additional RBG LED onboard, which will flash wildly in different colors, since it is driven by three DOs used for other purposes in the midibox standard. So I tossed my money in and ordered a new LPC. We will see, if it works properly and if all goes well, I'll have a spare LPC for a display less midibox application :-)

     

    Cheers, Andy

  5. Hey everybody

    As it seems, I fried the R/W output pin of my LPC17 (p1.27 of the LPC1769 xpresso).

    When I moved my Synth from the cardboard housing over to the new wood case, I accidentally plugged the 5V supply into J27 next to J2, the actual supply pins. 58a35c0127ad6_LPC17_LCDsection.thumb.PNG

    The 800mA slow blow fuse blew instantly, so I assumed, that I had shorted 5V to GND of J27 but everything except for the fuse  was alright. Of course, the move from one housing to the other lead to a lot of cables being too short and a bit of debugging due to shorts with the front panel and so on and so forth. The last thing to do, was to solder a longer cable to the KS0108 compatible GLCD, which at least for me is always a hassle to get the specific pinout as well as pullups, pulldowns and trimmerpots correct. After the first power on, the LCD started up normally with the init text, but then things got bad very quickly. After a couple of seconds, it continuously started looking more like a snow storm with random pixels being on or off, firstly changing, whenever the LCD was updated, but becoming static after a while. Meanwhile, with each power cycle, I either get a blank LCD or the mentioned snow storm. Of course, I doubted my skills first, checked the wiring several times, also changing RST high and low, but nothing helped. For a short time, I also believed that the 45cm long cable was too long, but the internet taught me otherwise. So I was left with two possible root causes, either the LCD has to be broken or the LPC. With the built in testlcdpin function, I was able to find R/W always being high (not mattering if an LCD is connected or not). This leads to my conclusion, that I probably fried the output of the LPC, since the pin is directly connected to the micro controller on the lpcxpresso board.

    Is there a possibility to assign another pin as the LCD R/W pin in a config file, so I can cut and rerout it to P1.27 on the lpcxpresso board and still be compatible with future updates? If this is not an option, does anybody know if the newly released LPC1769 board is fully compatible with the old version: http://www.mouser.ch/ProductDetail/Embedded-Artists/EAX00242/?qs=sGAEpiMZZMtWuggIubTlfyQKvxcc1sy3C%2fHLDQO4Us4%3d ?

     

    Thanks for your help! I am a bit in a hurry to fix this quickly, since I have to give up my electronics lab as soon as possible to make room for our firstborn :-) :-( :-)

    Cheers,

    Andy

  6. Hi Thorsten

    Ah, I got it. I have to first "save" each snapshot number (like set it up the first time) at least once, in order to "dump" values in it. As it seems, I haven't fully understood the difference between saving and dumping a snapshot. Can you please explain this? What I intend to do is simply store all current set values into a snapshot whenever I hit the button. Can I simply use save every time?

    How about the multiple banks of presets? Is my assumption correct, that I have to save them in different .NGS which would mean that I need to have copies of all configuration files with the same name as the corresponding .ngs for each .ngs?

     

    Thanks for your reply and best regards,

    Andy

  7. Hey everybody

     

    Today, I tried to get a step further with my synth and start configuring snapshot functionalities. Unfortunately, I didn't get very far. I can set snapshot numbers and save or dump them.

    I don't get the exact difference, but I belief that saving means that the last event state is being saved and dump means that all ID's states get saved (except the nodump ones). Can somebody confirm this assumption?

    As far as I understand, 127 different snapshots (127 times all ID's states) can be saved/dumped into one .NGS file. When I do this (via SCS standard menu or a self configured shortcut using the meta events DumpSnapshot and LoadSnapshot), the NGS file gets a bit larger, whenever I save to a new snapshot number. Also when I load a snapshot, I receive the line "loading snapshot #0 from /DEFAULT.NGS" in the MIOS monitor. If done via SCS menu, I get the confirmation on the LCD saying that all went well.

    However, no values get set if I load. Or in other words, if I dump two different snapshots and change one toggle button state, loading the snapshots won't load one or the other button state.

    I do load snapshot 0 in section 0 of my .NGR (at reset). This usually works and I get a "save state" in order for the synth to operate correctly. Unfortunately, sometimes, this dump gets corrupted as well and I have to dial in everything again. (@Thorsten: If you read this, the automatic dump every couple of seconds caused some timing problems which caused short audible interruptions when playing notes, so I had to disable it)

    Some special configurations of my Midibox could cause problems:

    - The load Snapshot 0 in section 0 might somehow trigger and reload dump Nr. 0. However, this should not happen and of course I tried without this code line and it didn't change anything.

    - I do have a couple of LEDs which I set in the .NGR script. I don't know if these get dumped as well and if loading also triggers the events which these sections get executed, so the LEDs get correctly set.

    - Some rotary switches trigger .NGR scripts which set LEDs in a binary fashion. Again, I am not sure if the states of these LEDs get dumped and if the scripts get triggered after reload. However, it doesn't work with simple events like

    EVENT_BUTTON id=  1088  type=CC    fwd_id=LED:2048  button_mode=Toggle  chn= 1 cc= 110 range= 0:127 lcd_pos=1:1:5  label="LFO Freq    ^highlow     "

    for example.
     

    Unfortunately, I don't get it how the .NGS file is structured in order to check how different snapshots differ.

    Does anybody have some experience with the whole snapshot thing and can give me some guidance?

     

    Should this all work one day, I would like to save some presets. Actually, I would like to try to convert the preset file from the original Moog Voyager and somehow upload these presets onto my midibox. I have Banks from A-E with 127 presets each. As far as I understand, "Bank" and "Patch" cannot be used for this, since these terms are used in different ways as they might suggest. The way I see it, I can do this by saving them in different .NGS files. However, I am not sure, if I have to create .NGC, .NGL and .NGR files with corresponding names in order for this to work as I would like or if multiple .NGS files can be loaded with one set of configuration files. Converting the original presets is going to be challenging, but maybe somebody has an idea how to do this as well?

     

    I am running Midibox NG V1.035 by the way.

     

    As always, help is very much appreciated.

    Cheers,

    Andy

     

     


     

    default.ngl

    default.ngr

    DEFAULT.NGS

  8. In case anybody else has a similar problem, here the solution: I figured out that whenever I had mi DSO attached to the FC line, the fourth AOUT_NG module worked fine most of the time. If I detached the probe after the initialisation phase of the midibox, the chip stopped working until I reattached it. This smelled like an AC termination issue, or better to say the lack of it. Since an AINSER64 in series with four AOUT_NG modules results in quite a long total cable length, these problems can occur. Basically, the signals can get reflected at the end of the line causing timing problems between the clock, FC and signal line. My solution was to terminate all three lines with 100ohms and 100pF to ground like the picutre below. Now everything works a treat again.

    ac_termination.gif

  9. Hi Thorsten

    Sorry for warming up this thread, but I've got trouble with my fourth AOUT_NG module again. After a break which unfortunately took me a couple of months, I started working on my synth again. I soon noticed, that something is amiss with the fourth board. The outputs don't react at all. To test correctly, I used a config file with a reset command and this single line "AOUT  type=AOUT_NG  cs=1  num_channels=32". Testing aouts with the caliaout command, I was able to test different outputs from 1-24. Everything worked except 25-32 on last board. Since I am pretty sure that they once did work, I switched the fourth board with a spare one, but nothing. So, I started interchanging boards as well as cables to rule out defective hardware. All boards and cables in any position work except for the fourth board in the chain.

    I did test with NG V1.033 pre16, V1.033 pre10 and V1.035

    Do you have any idea, what could be wrong in the software?

     

    Cheers

    Andy

  10. 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. :wry:

    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

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

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

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

     

  14. 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:

    IMG_1632.thumb.JPG.c8dcd7e9442bf9b909e1d

     

    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

     

  15. Could you please send me a (downstripped) .NGC file which allows to reproduce the problem at my side?

    Best Regards, Thorsten.

    Sorry, my fault. I figured out during stripping down the .NGC that I had one AINSER event routed to the same CV Out as the pitch CV. Why the note-on DOUT got triggered because of that, I don't know. However, consider it as solved.

    The Synth is really getting shape now. I am looking forward to post some audio samples or videos as soon as it sounds about right. But there are still a couple of little programming things to do first :-)

     

    Best Regards & have a nice weekend,

    Andy

  16. Aaaah, 2500ms did the trick. I already tried 500ms before, but this was obviously to short.

     

    "show id DOUT:1" only responds with "Invalid element name 'DOUT'!". But using "show id CV:4", i get the following values:

    After reset (Note on DOUT pin is low):

    [782449.918] id=CV:4 (hw_id=CV:4)
    [782449.918]   - bank=0
    [782449.918]   - condition: none
    [782449.918]   - fwd_id=DISABLED:0
    [782449.918]   - fwd_value=off
    [782449.918]   - fwd_to_lcd=1
    [782449.918]   - type=NoteOn
    [782449.919]   - chn=1
    [782449.919]   - key=128
    [782449.919]   - use_key_number=1
    [782449.919]   - ports=10001000000010000000
    [782449.919]   - value=424
    [782449.919]   - secondary_value=3
    [782449.919]   - map=0
    [782449.919]   - map_ix=0
    [782449.919]   - min=0
    [782449.919]   - max=127
    [782449.919]   - offset=0
    [782449.919]   - dimmed=0
    [782449.920]   - rgb=0:0:0
    [782449.920]   - syxdump_pos=0:0
    [782449.920]   - radio_group=0
    [782449.920]   - fwd_gate_to_dout_pin=3.D0
    [782449.920]   - cv_inverted=0
    [782449.920]   - cv_gate_inverted=0
    [782449.921]   - cv_hz_v=0
    [782449.921]   - led_matrix_pattern=Undefined
    [782449.921]   - colour=0
    [782449.921]   - lcd_pos=1:1:6
    [782449.921]   - label="^std_key"

     

    After first key press and release (Note on DOUT pin is high, the audible frequency defers from the key just pressed): 

    [782449.918] id=CV:4 (hw_id=CV:4)
    [782449.918]   - bank=0
    [782449.918]   - condition: none
    [782449.918]   - fwd_id=DISABLED:0
    [782449.918]   - fwd_value=off
    [782449.918]   - fwd_to_lcd=1
    [782449.918]   - type=NoteOn
    [782449.919]   - chn=1
    [782449.919]   - key=128
    [782449.919]   - use_key_number=1
    [782449.919]   - ports=10001000000010000000
    [782449.919]   - value=424
    [782449.919]   - secondary_value=3
    [782449.919]   - map=0
    [782449.919]   - map_ix=0
    [782449.919]   - min=0
    [782449.919]   - max=127
    [782449.919]   - offset=0
    [782449.919]   - dimmed=0
    [782449.920]   - rgb=0:0:0
    [782449.920]   - syxdump_pos=0:0
    [782449.920]   - radio_group=0
    [782449.920]   - fwd_gate_to_dout_pin=3.D0
    [782449.920]   - cv_inverted=0
    [782449.920]   - cv_gate_inverted=0
    [782449.921]   - cv_hz_v=0
    [782449.921]   - led_matrix_pattern=Undefined
    [782449.921]   - colour=0
    [782449.921]   - lcd_pos=1:1:6
    [782449.921]   - label="^std_key"

     

    After pressing the correct key with the same as the audible frequency (it turns out, that it is not always key 0 but this time was key 40) --> (Note on DOUT pin is low):

    [782449.918] id=CV:4 (hw_id=CV:4)
    [782449.918]   - bank=0
    [782449.918]   - condition: none
    [782449.918]   - fwd_id=DISABLED:0
    [782449.918]   - fwd_value=off
    [782449.918]   - fwd_to_lcd=1
    [782449.918]   - type=NoteOn
    [782449.919]   - chn=1
    [782449.919]   - key=128
    [782449.919]   - use_key_number=1
    [782449.919]   - ports=10001000000010000000
    [782449.919]   - value=424
    [782449.919]   - secondary_value=3
    [782449.919]   - map=0
    [782449.919]   - map_ix=0
    [782449.919]   - min=0
    [782449.919]   - max=127
    [782449.919]   - offset=0
    [782449.919]   - dimmed=0
    [782449.920]   - rgb=0:0:0
    [782449.920]   - syxdump_pos=0:0
    [782449.920]   - radio_group=0
    [782449.920]   - fwd_gate_to_dout_pin=3.D0
    [782449.920]   - cv_inverted=0
    [782449.920]   - cv_gate_inverted=0
    [782449.921]   - cv_hz_v=0
    [782449.921]   - led_matrix_pattern=Undefined
    [782449.921]   - colour=0
    [782449.921]   - lcd_pos=1:1:6
    [782449.921]   - label="^std_key"

    As described, everything works as it should afterwards.

     

    Best Regards, Andy

  17. Jup, I am very happy too, since I really was at my wit's end.

    To a) The Midi Keyboard is attached, running and the midibox also connected to MIOS studio. After the .NGC script is loaded, the assigned note on DOUT pin is low. But as soon as I hit the first key, using either the midi keyboard or the soft keyboard of the MIOS studio, the DOUT pin goes high and stays when I release the key. The only way to get it low again is to press the C-2 key (lowest in the scale) once. After that, the note on event acts as it should and only goes high as long as the key is pressed.

    To b) Except for the delay, this is what I wrote into the .NGR file. But for good measure, I copied your code and replaced mine to err out typers. The ^section == 0 gets executed (I checked with a "Hello World" to the LCD) but the show pool command in MIOS studio shows only zeros for all inputs. As soon as I move a pot, the actual value of this pot is shown if I do show pool again. I tried to switch the pot mode to direct instead of parallax but this does not change anything.

     

    Best Regards, Andy

  18. Hey TK

    You're the man! All fine, the AINSER doesn't affect the DIO Matrix anymore. Thank you very much for your super fast support.

    Now I only have to figure out why I ...

    a) always have a "note on" event staying on, when I hit a key on the midi keyboard attached for the first time after restart. It stays on until I hit the lowest note of the keyboard once. I already tried to set another dout pin to rule out an overflow of the DIO matrix scan pattern, but get the same effect.

    and ...

    b) why my .NGR script always only writes 0s into the .NGS file during startup. I do have to slightly turn every single knob once to get the AINSER values and output them to the AOUTS. So I was not able to test the parallax mode yet. However, I haven't implemented a menue with a manual dump and load snapshot command.

     

    Anyways, you brought me a huge step further with my project. I owe you one.

    Cheers,

    Andy

  19. Hey Thorsten

    Unfortunately, the pre12 didn't have the expected effect and I still get the same scanning sequence. But you are definitely close. I changed all the ain_modes to "direct" and repeatedly get the following sequence as soon as the error occurs:

    [607193.357] Page  0: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.357] Page  1: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.359] Page  2: 5f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.360] Page  3: 6f 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.361] Page  4: 77 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.361] Page  5: 7b 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.363] Page  6: 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.363] Page  7: 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.365] Page  8: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.365] Page  9: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.367] Page 10: 5f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.367] Page 11: 6f 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.369] Page 12: 77 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.369] Page 13: 7b 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.371] Page 14: 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.371] Page 15: 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.373] Page 16: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.373] Page 17: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.375] Page 18: 5f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.375] Page 19: 6f 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.377] Page 20: 77 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.377] Page 21: 7b 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.377] Page 22: 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.379] Page 23: 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.379] Page 24: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.381] Page 25: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.381] Page 26: 5f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.383] Page 27: 6f 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.383] Page 28: 77 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.385] Page 29: 7b 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.385] Page 30: 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [607193.386] Page 31: 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    Changing back to parallax results in the old wrong sequence again.

    I hope, these info helps for further debugging.

    Best Regards,

    Andy

     

  20. As soon as the error occurs, I get:

    [523254.412] Page  0: 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.412] Page  1: af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.414] Page  2: cf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.414] Page  3: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.416] Page  4: e7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.416] Page  5: eb 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.418] Page  6: ed 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.418] Page  7: ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.419] Page  8: 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.419] Page  9: af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.421] Page 10: cf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.421] Page 11: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.423] Page 12: e7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.423] Page 13: eb 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.424] Page 14: ed 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.426] Page 15: ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.426] Page 16: 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.428] Page 17: af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.428] Page 18: cf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.428] Page 19: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.430] Page 20: e7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.430] Page 21: eb 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.432] Page 22: ed 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.432] Page 23: ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.434] Page 24: 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.434] Page 25: af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.436] Page 26: cf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.436] Page 27: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.436] Page 28: e7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.438] Page 29: eb 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.438] Page 30: ed 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [523254.439] Page 31: ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    before that, all is well. I used this command several times when I had the error with the same sequence. I'm wondering how this zero gets to the fifth position of the string. But of course, all is off afterwards.

     

    Also, if I disable AINSER, the error never occurs. Also with AINSER and AOUT. But with AOUT off and AINSER on, I have the problem regularly. So it's the AINSER command which seems to have something to do with the problem.

     

    I didn't have a .NGR but now do have one with the following in it:

    if ^section == 0
      exec_meta RetrieveAinserValues
      exec_meta DumpSnapshot
    endif

    ...since I accidentally had it in the .NGC which didn't work of course. Unfortunately this also doesn't initialize the Ainsers somehow. So I have to turn each knob once to initialize it until I can test the synth.

     

    Cheers

    Andy

  21. Please do following test before we continue with software based troubleshooting: once the circuit becomes unstable, enter the "reset" command in MIOS terminal -> is the circuit stable again, or does it stay unstable?

    Best Regards, Thorsten.

    Hey Thorsten

    Good point. Yes, it does get stable again when I reset via the terminal.

    One new finding is, that if I disconnect the AINSER64 from J19 of the Processor board and the AOUTs subsequently, I cannot provoke the error on the DIO-Matrix anymore regardless of whether or not I have the DIO-Matrix supplied separately from the PSU or not. The scope shows the same noise of +/-60mV at the 5V rail. I checked, if the problem also occurs if the AINSER is connected without the AOUTs and the answer is yes. So the question arises if this is a software bug which only happens if AINSER64 is connected or if it has something to do with interference from the AINSER64 scan cables. But even if I turn a pot which is on a strand 20cm away from the DIO-Matrix cables, the problem still occurs. If I disconnect the scan cables of the AINSER64 which cross my DIO-Matrix cable, and the processor goes into unlimited value change scanning at these lines, the error of the DIO-Matrix occurs instantly. One last thing I can test is if the error can be provoked if I disconnect the crossing lines but also ground these inputs in order to not having value changes at these inputs all the time.

    Find the whole config file. Maybe there is a clue about the problem in there:

     default.ngc

     

    Thanks guys for bearing with me and best regards,

    Andy

  22. You're right...here is what we are talking about:

    IMG_1621.thumb.JPG.8977a82899b1199fa6ad3

    Marked red is the DIO Matrix board close to the processor right below (8cm ribbon). Then green is the distribution board which is connected with two 20cm flat flex cables and orange is another 20cm flat flex with three LED push button boards (two mounted on the front panel and the one with visible buttons floating). In the back you can see the rotary switches also connected to the distribution board and the smaller parts are pots connected directly to the AINSER_64.

    Ignore the other ribbon cables in the lower part of the image. These are temporary CV connections of the analog section. I don't think they can be causing interference, since the CVs are all static voltages from the AOUT_NGs so far (no modulation yet). The audio path is running through shielded cables.

    I know, the front panel cabling is a terrible mess, but so far I don't see a better solution for parts mounted such far away from each other. Everything will be tidied up with cable ties in the end, but that won't help if the cables of the DIO and the AINSER scanning matrices are even closer together. Since the front panel is over 60cm wide, PCBs won't be a good solution to connect the parts either.

     

    Cheers,

    Andy

     

     

×
×
  • Create New...