mumblecake
-
Posts
63 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by mumblecake
-
-
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:127ngr:
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
endifif ^section == 2
log "Off"
endifif ^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=OnOnlyand ngr:
if ^section == 1
log "section 1"
delay_ms 100set LED:33 0
set LED:34 0
endifI 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?
-
This configuration will only set the value of the LED, but it won't trigger the action (it won't execute the meta command)
For such purposes I introduced the SENDER event; so if you write:
#should forward when incoming signal is the correct channel, correct cc and value=0 EVENT_RECEIVER id=1 fwd_id=sender:33 type=CC chn=5 cc=1 range=0:0 #should forward when incoming signal is the correct channel, correct cc and value=127 EVENT_RECEIVER id=2 fwd_id=sender:34 type=CC chn=5 cc=1 range=127:127 # run section 1 EVENT_SENDER id=33 type=Meta meta=RunSection:1 # run section 2 EVENT_SENDER id=34 type=Meta meta=RunSection:2
the run script section should be executed.
From the section you can switch the LED, e.g. "set LED:33 127" will turn it on, and "set LED:33 0" will turn it off
Best Regards, Thorsten.
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:2unfortunately 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
-
I think you're wright about building a new core won't solve the problem, cause the problem is in some basic (wiring) thing. But sometimes I get stuck and starting over again clears a lot.When I first soldered my buttonboard, see picture, I soldered it wrong. My buttons were like 2,1,4,3,6,5,8,7. So I re-soldered the first row and checked it again. Now it was good, so I copied the other rows. After I plugged them in I noticed the strange behaviour like I mentioned before. I thought I soldered it wrong again, so I attached button row 1, wich was good on SR1, to SR2 and it did the same strange mirror thing. So I'm quite shure the button rows are soldered correctly. I even tried to shortcut the pins from SR2 to ground and see what happens, and the mirror thing is still there.That's why I started thinking I maybe changed the DIN pinout on the software side. But I guess that's not possible,I installed a new bootloader and formatted the SD Card, and the problem is still there with the new DEFAULT.NGCAnyway thanks for your replies, I hope tomorrow will clear things up.
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.
-
Hi TK,
thank you very much for the explanation. Yes, it is indeed clear now. Less clear is however why I was so worried about a 5ms latency when I was completely oblivious to the fact that I would get a whopping 28ms latency from my soundcard.
I think at some point I will need to invest into a better proper ASIO soundcard (atm using a x-fi titanium with ASIO4ALL drivers ... creative drivers don't work properly) ;)
thank you very much again. I start to see light at the end of the tunnel of this project.
best regards
Mathis
-
Hi Thorsten,
I played around a bit now and have to say that it works like charm. Absolutely brilliant. I'm trying to better understand what num_sr means: Does a number of num_sr=4 mean that four DI and four DO chips get scanned or is it two and two?
I have three more DIN and DOUT boards that need addressing. Does that increase my shift register count by 12 (four per board)?
thank you very much. My worry of latency certainly isn't one anymore
best regards
Mathis
-
I just have added a new parameter to the .NGC file.
Just upload this prebuilt binary: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip
Now you can reduce the number of scanned SRs with (for example):
SRIO num_sr=4
in your .NGC file
Best Regards, Thorsten.
Hi Thorsten,
that's big news, not just for me I would think!
thank you very much, I will see to testing this new build asap.
best regards
Mathis
-
Measuring with the oscilloscope a din matrix scan cycle for 8 rows takes ~3.5ms. Am I right to think that 16 rows would take about 7ms and having one 8 row matrix + one 4 row matrix should stay at 3.5ms (giving the advantage to separating manuals and pedalboard)?
thanks a lot
Mathis
-
I have done the mapping and it turns out that it is in a pattern of (if you number the keys from left to right: C=1 C#=2 D=3 D#=4 ...):
16 1 15 2 14 3 13 4 12 5 11 6 10 7 9 8
I have attached the resulting ngc file (had to rename it to txt as the forums software would otherwise not let me upload) for the interested one.
A question towards latency. With the kb driver I would have to expect a latency of ~3ms for a full keyboard.
Is this comparable when using the din matrix driver instead (after all it must handle a lot more events in comparison to the one kb event which handled all inputs)?
Is there a latency advantage when using one 8x16 matrix (both keyboards) + one 4x16 matrix (pedalboard) in comparison to one 16x16 matrix (I've done the former in my ngc file)?
thanks a lot for all your help and input
best regards
Mathis
-
Hi Thorsten,
yes they are indeed 2 keyboards + pedal board ( 61 + 61 + 32 keys)
I have a look into the din matrix. Looking through the mappings on my keyboard I'm stunned ... they must have been drunk when they designed that. It's crazy!
I really want to avoid a bespoke software version (aka maintenance hell if too many of those code fragments accumulate) and will have a look at the DIN matrix solution.
thanks a lot
best regards
Mathis
-
Hi Thorsten,
thank you very much. I think that would help indeed. Would that be a lot of effort? The alternative attempt I was going to make was to grab out the keys in group of 8 using event_kb with different ids and transpose them accordingly.
Before you go to great lengths I would like to give that a shot first.
Just a quick question: The range of input keys seems to be limited to 128 (all examples show: range = 0:127). Is it not possible to capture the full 256 keys with two DIN and two DOUT modules defined in the kb driver?
thank you very much
best regards
Mathis
Help with configuration.
in MIDIbox NG
Posted · Edited by mumblecake
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.