mumblecake

I would very much doubt that the double assigning of IDs plays a role if it works three times. You said that you double checked all the midi hardware, exchanging the SR chips etc. How difficult would it be to swap your displays. E.g. swap display 3 & 4 and see if it is still display 4 which makes the trouble? Just to try to narrow down the problem. Do you have a scope which you could use to debug the signals. It's all very mysterious ...

Awesome. Really happy for you :D

Finally got all 43 SAMs wired in (43 digital in + 86 digital out) I wanted to quickly give a configuration reference in case someone in the future wants to do something similar (this thread has captured quite a few of the caveats of the configuration and scripting). To freshen up. I set out to do the following: Firstly: it needs to be possible to manually change over the SAM. The controller should recognise this and send out a midi signal to the computer (cc signal) Secondly: An automatic change is requested by an incoming midi signal (same cc signal). - If the SAM is already in the requested position: don't do anything. - the requested value is different - The script should now disable the opposite coil (just in case it was still active) - it should activate the correct coil - wait for 100ms (I do not want to wait on the din as if the button is stuck we get to a situation where the current stays on indefinitely) - switch the coil off (probably best to switch every coil off) - if the digital input flips it should ignore this and not send out a midi signal as it is simply obeying a command. The computer expects the command to having been executed and doesn't need confirmation one problem was that when you fire a script section while the previous iteration hasn't finished executing yet, the previous execution will be stopped and a new one will be launched. This meant that only a wait and a switch off command could go into the script as otherwise anything before the wait would possibly not get executed. So here it is: my digital in is on Button:65 while my digital outs are on LED:33 (Off coil) and LED:34 (on coil) ngc: #part for manual switch actuation. Sending of the CC event needs to be part of separate sender as otherwise "if_equal" comparison with button value will fail EVENT_BUTTON id=65 fwd_id=sender:1 EVENT_SENDER id=1 type=CC chn=5 cc=0 #part for automated switch actuation. Forward to forking logic as part of Senders with hw_id=101 EVENT_RECEIVER id=1 fwd_id=sender:101 type=CC chn=5 cc=0 #if requested off go to Senders with hw_id=102 EVENT_SENDER id=101 hw_id=101 if_equal=0 fwd_id=sender:102 #if requested on go to Senders with hw_id=103 EVENT_SENDER id=102 hw_id=101 if_equal=127 fwd_id=sender:103 #switch off logic. If Switch is in on position activate off coil and deactivate on coil. Also start script section 1. If switch was already in off position: don't do anything EVENT_SENDER id=103 hw_id=102 if_equal=button:65:127 fwd_id=LED:33:127 type=Meta meta=RunSection:1 EVENT_SENDER id=104 hw_id=102 if_equal=button:65:127 fwd_id=LED:34:0 #switch on logic. If switch is in off position activate on coil and deactivate off coil. Also start script section 1. If switch was already in on position: don't do anything EVENT_SENDER id=105 hw_id=103 if_equal=button:65:0 fwd_id=LED:33:0 type=Meta meta=RunSection:1 EVENT_SENDER id=106 hw_id=103 if_equal=button:65:0 fwd_id=LED:34:127 ngr: if ^section == 1 #deactivate sending of messages. An automated change request has been made ... I don't need to inform the origin of the change request that the change has been performed set_active (id)SENDER:1 0 #wait 100ms ... that's roughly how long it takes for the switch to change. delay_ms 100 #switch has now been fully actuated. Reactivate sending of values to become responsive to manual changes again. set_active (id)SENDER:1 1 set LED:33 0 set LED:34 0 endif hope that might be useful to someone at some point. BR Mathis

not sure that your event definition will work correctly. You have used the Sender ID = 4 twice. Try EVENT_RECEIVER id=4 fwd_id=SENDER:4 range=0:127 type=CC chn=1 cc=104 EVENT_SENDER id=4 hw_id=4 fwd_id=LED_MATRIX:2 EVENT_SENDER id=5 hw_id=4 fwd_id=LED_MATRIX:1 and see if that makes a difference.

Try something like this: EVENT_AINSER id=3 type=Aftertouch ain_mode=switch chn= 1 range=0:127 it says that you also have to define a key value I assume that aftertouch is a switch rather than analogue which is why I would try using the ain_mode=switch attribute. if the signal is inverted you can re-invert the signal by using range=127:0 as I said I have no experience with aftertouch so just have a little play with it :)

Hi Michał, This sounds that it is actually a switch and should be on a DIN. Either way I would definitely attach it to Vs and invert the signal or map the signal as part of the configuration. cheers Mathis

I know that this is kind of old but I hope you haven't given up on the project yet. You said that you were using the DIN and DOUT modules. Have you had a look at the wiring of the manuals. I guess that you are dealing with a diode matrix, can you confirm this? While it is possible to use the DINs and DOUTs you are kind of left to the mercy of your diodes being the right way around. In the mean time the DIO matrix board has been released which has a jumper giving the option to use a diode matrix which is the other way around. I'm saying this as my project consists of old Rodgers manuals which have the diodes the "wrong" way around. I would also carefully suggest to upgrade to one STM32F4 Core board and then use midibox NG (I'm confident that we should manage to squeeze your organ onto one controller). Do you have an oscilloscope to your disposal ... this greatly helped me to check if I was dealing with a hardware problem or a software configuration problem. Could you give the specs of the organ that you want to midify: number of manuals, how many notes on the pedalboard, number of thumb/toe pistons, expression pedals and stop tabs (when you look at the back of the stop tabs aka stop action magnets (SAMs), how many coils do you see? One or two?). I might be able to help with planning the wiring. If you use midibox NG (you need the new controller for it) I could also help configuring the controller. In particular the SAMs are quite tricky and I'm not totally sure that the old PIC based cores could actually deal with them: read here on the current progress on getting them to work: Either way if I'm confident that we will be able to point you in the right direction if you get stuck :)

Hi Michał, I can't find wiring diagrams for aftertouch strips. I would however be very surprised if the strip does not have a ground reference. My guess is that it is piezo based in which case the strip will generate a voltage on stress/pressure. Try connecting it to Vs (aka ground) and A3 and respectively Vs and A4. Edit: the Vd (supply voltage) on the AI connectors is mainly used to correctly use potentiometers as potential dividers. Edit 2: thinking more about it. If you reference your aftertouch strip at the supply voltage you should read in a value which will be close to the maximum. You will get some noise on the measurement due to unshielded wiring and thus EMF pick up. If you now press the strip your reading will be over the limit of the analogue in which means it should stay steady at the maximum reading meaning it will stop to seem noisy ... simply as it is coerced to the maximum. If that's the case using Vs should solve your problem.

Am I right to think that your two aftertouch strips and the pedal are coming in as analogue inputs as well (apologies for my ignorance but I'm not using my midibox for synths)? If so they should be added on your AINSER board as well. Considering that you are only using 7Bit resolution and the number of analogue inputs is quite small, have you considered using the core AIs? My knowledge of midi is quite limited (so apologies for any blatant ignorance) but it seems to me that you are starting to overload your channel a bit. I assume that a single channel can handle CC signals, note signals and Pitchbends on the same channel as they are all different signal types but if you start adding analogue signals I wouldn't be surprised if you have to start using additional channels. I'm not really expecting to have answered anything, just try to get the conversation going until one of the forum veterans joins in :smile:

Once I'm done with the physical build of my organ I will have a look at the source code. I was looking for an interesting project to brush up my text based coding skills (job wise I'm only doing Mickey Mouse coding aka LabVIEW ;)). Don't expect any results within the next 2-3 months though.

Hi, due to the very limited RAM on some NG platforms (LPC17 & STM32) and due to ongoing support for all platforms decision was made to parse the script file from the SD card on each call of a script section. I am completely aware that in particular on the LPC17 and the STM32 platform loading the ngr into RAM is not feasible as the RAM is simply not sufficient. On the STM32F4 however it could be done if the event definitions of both ngc and ngr would fit in. What I propose is a flag in the ngc file: pre_load_ngr 0/1 which gets placed at the beginning of the ngc file. When the parser gets to the point of the flag it would then analyse the necessary size of ngc + ngr event definitions. If the RAM size of the core is insufficient it ignores the flag and proceeds as normal with parsing the script from the SD card on each call. If the RAM size is sufficient it stores the script in RAM (either bare string which gets parsed on each call or already in a parsed and more machine friendly form) and calls it from there on each section call. What do I hope to achieve with this: It's a neater solution compared to parsing the file from disk every time. More importantly though: I hope to achieve higher long term reliability. I execute safety critical code as part of my script (safety critical for the equipment) and if the SD card would give up while the core is still running I get a good go at frying my stuff. Without having spent any time on the source code I'm not really able assess how feasible my suggestion is, so apologies if I just made a preposterously difficult proposal ;) BR Mathis

Hi Michał, could you attach or post your configuration, please (KB and NG, please)? In my experience it is usually small things the cause it not to work. I'm sure we can get to the bottom of this quite quickly once you post your configuration. cheers Mathis

Ohhh, so the button is also receiving the midi command ... I though it was only sending it. Ok, I will decouple the button and the message sending by introducing another sender. Will see how feasible this will be ... even if it works it will clutter the ngc file quite badly ... I might just end up accepting the solenoid activation for simplicities sake. Thanks a lot for shedding some light on this. BR Mathis

ok, it has nothing to do with the call stack. Taking out the if_equal=button:72:?? meant that it continued running. Why does it fetch valid values for this when the event chain is launched by a button but not when it is launched by a receive event?

Hi, I've got another question. I have the following: ngc: EVENT_BUTTON id=65 type=CC chn=5 cc=0 fwd_id=sender:8 EVENT_BUTTON id=72 type=CC chn=5 cc=7 EVENT_RECEIVER id=8 fwd_id=sender:8 type=CC chn=5 cc=7 EVENT_SENDER id=13 hw_id=8 if_equal=0 fwd_id=sender:9 type=Meta meta=RunSection:2 EVENT_SENDER id=14 hw_id=8 if_equal=127 fwd_id=sender:10 type=Meta meta=RunSection:3 EVENT_SENDER id=15 hw_id=9 if_equal=button:72:127 fwd_id=LED:47:127 type=Meta meta=RunSection:1 EVENT_SENDER id=16 hw_id=9 if_equal=button:72:127 fwd_id=LED:48:0 EVENT_SENDER id=17 hw_id=10 if_equal=button:72:0 fwd_id=LED:47:0 type=Meta meta=RunSection:1 EVENT_SENDER id=18 hw_id=10 if_equal=button:72:0 fwd_id=LED:48:127 ngr: if ^section == 1 #log "section 1" delay_ms 50 set LED:33 0 set LED:34 0 set LED:35 0 set LED:36 0 set LED:37 0 set LED:38 0 set LED:39 0 set LED:40 0 set LED:41 0 set LED:42 0 set LED:43 0 set LED:44 0 set LED:45 0 set LED:46 0 set LED:47 0 set LED:48 0 endif if ^section == 2 log "Off" endif if ^section == 3 log "On" endif The idea is the following: Up to now the solenoids would have always engaged when an external midi command came in. I wanted to change that so that the solenoids would only engage when their respective button (Button:72) was in the wrong position. Therefore I have split the received message into the cases of "off" and "on" (Sender IDs: 13 & 14) and forwarded those to the sender events which should switch the button off (Sender: 15 &16) or on (Sender: 17 &18) For testing purposes I also attached the same mechanism to another button (button:65). I also created new dummy scripts to be able to follow what is happening. When I actuate Button:65 everything works and Button:72 is repeating the state of 65. There are no log messages in MIOS Studio which is not surprising as the scripts which would display "on" or "off" get cancelled in the chained event which launches script section 1. When send the correct midi signal nothing moves but I get "on" and "off" displayed in the MIOS studio meaning that the event did not get forwarded and section 1 never launched. This is surprising me as the maximum nesting level of four is not reached (should be two unless I'm counting wrong). Does anyone have an idea? edit: could it have to do with timing in that the when the midi command is received that the current state of button:72 is not available while when actuating button 65 it still is, as the read out has just finished?

Quick question: The ngc config needs to have a 6 Bit enable mask for the onboard AIs: e.g. AIN enable_mask=110000 the Core_STM32F4 does however provide 8 AIs do I need to make the mask an 8 Bit mask in order to not leave the last two AIs in an ambiguous state (I only want to use 2 AIs)?

At first I had the wires swapped on the DOs which meant that as the DI was always creating a midi signal on change that I created a nice flip flop. Managed to pull the plug of the PSU for the coils before anything started to disintegrate. I quickly made the same swap in the config and everything started working: A manual change changed whether the stop was pulled or not in the software while a click in the software changed the physical position of the switch. Soooo satisfying when everything starts to come together. More determined than ever to see this project through to the end!

It works !!!!!!!!!! :D

Hi Thorsten, this is amazing. Thank you soooo much. I'm getting really close now. I can almost feel it (though still loads of work to) ;) I would start literally jumping for joy if I wasn't surrounded by colleagues who would look very bewildered. So happy in the prospect of getting past this stage of the project. BR Mathis

OK, it doesn't work but I don't fully understand why. I have at the moment: ngc: # run section 1, switch on LED 33, switch off LED 34 EVENT_SENDER id=1 hw_id=1 type=Meta meta=RunSection:1 EVENT_SENDER id=2 hw_id=1 fwd_id=LED:34:0 EVENT_SENDER id=3 hw_id=1 fwd_id=LED:33:127 # run section 2, switch off LED 33, switch on LED 34 EVENT_SENDER id=4 hw_id=2 type=Meta meta=RunSection:1 EVENT_SENDER id=5 hw_id=2 fwd_id=LED:34:127 EVENT_SENDER id=6 hw_id=2 fwd_id=LED:33:0 # using buttos rather than receive events for testing EVENT_BUTTON id=33 fwd_id=sender:1 type=CC chn=4 cc=0 button_mode=OnOnly EVENT_BUTTON id=34 fwd_id=sender:2 type=CC chn=4 cc=1 button_mode=OnOnly and ngr: if ^section == 1 log "section 1" delay_ms 100 set LED:33 0 set LED:34 0 endif I can see that the script is getting fired but none of the LEDs seems to get engaged now (or all at once ... nothing moving) any ideas?

That's brilliant. Thank you Thorsten! Would this work (sorry, I'm at work right now, otherwise I would just give it a whirl rather than asking)? #should forward to Senders with hw_id=1 when incoming signal is the correct channel, correct cc and value=0 EVENT_RECEIVER id=1 fwd_id=sender:1 type=CC chn=5 cc=1 range=0:0 #should forward to Senders with hw_id=2 when incoming signal is the correct channel, correct cc and value=127 EVENT_RECEIVER id=2 fwd_id=sender:2 type=CC chn=5 cc=1 range=127:127 # run section 1, switch on LED 33, switch off LED 34 EVENT_SENDER id=1 hw_id=1 fwd_id=LED:33:127 type=Meta meta=RunSection:1 EVENT_SENDER id=2 hw_id=1 fwd_id=LED:34:0 # run section 2, switch off LED 33, switch on LED 34 EVENT_SENDER id=3 hw_id=2 fwd_id=LED:34:127 type=Meta meta=RunSection:2 EVENT_SENDER id=4 hw_id=2 fwd_id=LED:33:0 What I'm trying to do is getting the "switch on/off" out of the script so that it doesn't matter if the script gets cancelled before the LED got switched. The script would only contain the wait and a "switch all 86 LEDs off". So even if my organ software sends 20 midi signals to get 20 stop action magnets (deutsch: Registerknoepfe) changed it would activate all 20 LEDs/solenoids and deactivate the respective opposites. The script would start executing 19 times and each time get interrupted. On the twentieth run, the script would however run through and deactivate everything at the end. I have decided that the case of commands coming in every 10, 20 even 100ms is unlikely and I can't afford looking for a solution that covers that requirement. For now I also ignore the fact that once the BUTTON gets switched by the solenoids it is going to repeat the signal that was initially requested ... it shouldn't do any harm. That means that if I could manage to activate one LED, deactivate another and start the script I would basically be done.

I'm struggeling a bit (with the simple stuff unfortunately) I would like to forward midi events to their respective LEDs: E.g. I get a midi signal: ch5 cc=0 value=0 I want to forward this event to LED:33 I get a midi signal: ch5 cc=0 value=127 I want to forward this event to LED:34 from the respective LEDs I would like to start the correct section of the script. I started with something like this: #should forward when incoming signal is the correct channel, correct cc and value=0 EVENT_RECEIVER id=1 fwd_id=led:33 type=CC chn=5 cc=0 range=0:0 #should forward when incoming signal is the correct channel, correct cc and value=127 EVENT_RECEIVER id=2 fwd_id=led:34 type=CC chn=5 cc=0 range=127:127 # should switch on LED:33 and run section 1 EVENT_LED id=33 type=Meta meta=RunSection:1 # should switch on LED:34 and run section 2 EVENT_LED id=34 type=Meta meta=RunSection:2 unfortunately this doesn't work. Even when I replaced the receiver events with button events and forwarded to the LEDs, it never started the script sections. Any insight into what I'm doing wrong would be much appreciated

Hi Thorsten, thanks for reply. I installed the update but it doesn't change anything about the timing of the delay_ms. I turned the SRIO num_sr subsequently off for testing and the timing was still out by a factor of 2. Will poke my scope in at some point to get a more quantitative measurement. Doesn't really matter at the moment was just a noteworthy find. I think you are underestimating what you have achieved with NG. I do think that it is possible with the right combination of meta events and ngr scripting (activating and deactivating meta events when needed). I think that it definitely is possible just not as straight forward as all other steps to this point. I'll get to work and try to prove you wrong (I take it that you won't mind that) ;) BR Mathis

Hi, I have now finally come to a stage with my organ project at which I can start scripting my ngr file. In order to speed up my keyboard scans I have used the relatively new option to define the maximum number of shift registers (SRIO num_sr=16) which I think might explain the behaviour which I'm describing in the following. I played a bit around with the scripting and in particular the delay functions. The script was as simple as: if ^section == 0 Log "start" delay_ms 1000 Log "end" endif The script was fired on a button press. But rather than seeing a delay of 1 sec between the two messages I saw only half a second. Could it be that the delay_ms is somehow coupled to the defined number of shift registers and that by halving that my delays halve as well? Another thing I noticed is that if I press the button while the previous script is still running it seems to abort the script and start it again. Is that intended behaviour? Meaning: <press button first time> MIOS studio: "start" <press button another time> MIOS studio: "start" <wait> MIOS studio: "end" This brings me to my specific application and I was hoping someone could give me an idea of how to approach this, as if done wrong I can fry quite a bit of my equipment. I have stop action magnets (SAM) for the organ. Those have a digital output (reed switch) indicating if they are on or off (normal DIN). You are also able to automatically change the switch over to a certain position. For this the SAM carries two coils, one used to switch the SAM on and one to switch it off (DOUT/LED with ULN darlington transistor). The coils are operated with a 15V PSU, draw 0.5A current and are quite small ... too small as if they could dissipate 7.5W. It is therefore key that neither coil gets activated for longer than ~100ms as otherwise I would risk to burn out the coil. There are now two operational modes which the controller needs to cater for: Firstly: it needs to be possible to manually change over the SAM. The controller should recognise this and send out a midi signal to the computer (cc signal) Secondly: An automatic change is requested by an incoming midi signal (same cc signal). - If the SAM is already in the requested position: don't do anything. - the requested value is different - The script should now disable the opposite coil (just in case it was still active) - it should activate the correct coil - wait for 100ms (I do not want to wait on the din as if the button is stuck we get to a situation where the current stays on indefinitely) - switch the coil off (probably best to switch every coil off) - if the digital input flips it should ignore this and not send out a midi signal as it is simply obeying a command. The computer expects the command to having been executed and doesn't need confirmation Now the things I'm worried about. I have 43 of those SAMs and a lot of commands can come in in quick succession. The ngr file takes about 5ms to load for each called script section. How can I ensure that the coils are actually being switched on if a successive script call is going to cancel the previous one which started less than 5 ms ago and hasn't activated the coil yet? Then how can I ensure that the coils are switched off after 100ms and lets say an absolute maximum of 200ms: Let's say I alternate through all 43 SAMs with 10ms delay. That means the new coils would all get set but the delay_ms will never finish and no coil would ever get switched off. It would be great if someone more experienced could shed some light on how to best approach the problem thanks a lot best regards Mathis

Hi, in order to exclude a problem with the smashtv boards you could try to disconnect your button array and test each contact on the smash boards by using a jumper cable between ground and the individual DI pins, at the same time checking in MIOS studio that you get the expected button events.