Controlling SAMS Help Needed

Hey folks,

I'm controlling some SAMs with a pair of MIDI Boutique MDDP128. I have the programming and everything working like it should - MIDI channels are mapped correctly, they go up and down (mostly like they should) but it is exhibiting some odd behavior.

Here is a video link of the partial issue:

https://www.youtube.com/watch?v=NUYLD5hzIag

The stop "tabs" on the screens are "fluttering," even though the SAM is clearly on. It only does this when using large registration changes.

I also have some issues with everything staying in sync. When setting a combination piston, is there a way to force the software to take the "on/off" state FROM THE STATE OF THE SAM, and not from within the software? This seems like it would maybe solve this issue. If the state of the stop could ONLY be controlled by the state of the SAM output, then it would be impossible to get out of sync.

Sometimes SAMs engage correctly, sometimes they don't. The general cancel tends to clear everything 90% of the time, but if I have one piston turning everything ON, sometimes I have to press it a time or two to get everything "down" and even then, it will only allow the stop tab to go down (ON) IF the stop is actually OFF inside the software.

Any general advice, here? I have used this concept on other projects but I've never had any issues before. Maybe it's the SAMs themselves? I am also wondering if the "fluttering" maybe has something to do with the EMI from the solenoids engaging?

Any general advice here would be welcomed from anyone with experience doing this.

Thanks,
Drew

I suspect either the SAMs are generating bounce beyond the filtering of the board, or you have a feedback loop going on. There is a way to set up the switches in Hauptwerk so feedback doesn’t happen, but I can’t recall it at the moment. Feedback may also happen at other components of the midi chain. Try to simplify the Midi input chain and see if that helps. Can you adjust the bounce on the Midi Boutique driver board? I’m not very familiar with that model.

[mdyde]

Hello Drew,

To add to Larason2's reply:

Although I don't have experience of wiring SAMs or MIDI Boutique MDDP128 myself, my thoughts would be:

- If possible, make sure that the MIDI encoder/decoder is not 'echoing back' state changes that it receives from Hauptwerk. I.e. if the SAM gets turned on from Hauptwerk then ideally the encoder should send no MIDI messages at all back to Hauptwerk in reply (otherwise you may get a timing-dependent feedback loop). I would imagine there may be a setting in the encoder's firmware for that.

- If you right-click on the virtual stop in Hauptwerk to configure its MIDI settings manually, then go to the MIDI output tab, there is an option "Always suppress output (echo) if direct response to input". Try ticking that if it isn't already ticked.

- Try to make sure that SAM switch contacts aren't bouncing. The encoder may have a firmware option/mechanism to try to suppress it if it does occur.

- Use a good-quality MIDI interface that has plenty of hardware MIDI buffering, e.g. a MOTU Express 128 or Microlite.

- If you have lots of SAMs and multiple encoder boards you might perhaps want to split them up across multiple MIDI ports. E.g. use several MIDI IN, and several MIDI OUT, ports on a multi-port interface, such as an Express 128, to aid with timing (MIDI is a slow) and to help reduce the risk of encoder/decoder MIDI buffer floods.

- If there's a setting in the encoders/decoders for how much MIDI buffering to use then set it to an ample value.

When setting a combination piston, is there a way to force the software to take the "on/off" state FROM THE STATE OF THE SAM, and not from within the software? This seems like it would maybe solve this issue. If the state of the stop could ONLY be controlled by the state of the SAM output, then it would be impossible to get out of sync.

No -- it isn't in general possible within the MIDI 1.0 standard to query the states of external MIDI controls.

I have a Midi Boutique decoder installed at a church in McMinnville, Oregon. If necessary I can make a trip there and check the settings as that capture system has been working without incident for over five years now. I've frequently seen fluttering SAMs as opposed to fluttering virtual displays, but in either case it's possible that the auto-detect sequence happened in reverse order in addition to the configuration items that Martin mentioned in his post. I believe that if HW sees an off-on sequence instead of on-off that the SAM and virtual display can get out of sync. Perhaps I'm mistaken here as I cannot test this idea at the moment. Perhaps someone can confirm this?

Ideally encoders and decoders (or a combined unit) will be aware of the states of all the SAMs and will be able to differentiate between actions initiated at the console and those coming first from HW. Additionally it's good if the decoder does not try to activate a SAM that is already in the correct position. HW breaks the feedback loop in any case by suppressing echos when necessary. The encoder/decoder ideally does a similar suppression.

I'll look through my stack of notebooks for the Midi Boutique settings as I think I saved them.

[mdyde]

I believe that if HW sees an off-on sequence instead of on-off that the SAM and virtual display can get out of sync. Perhaps I'm mistaken here as I cannot test this idea at the moment. Perhaps someone can confirm this?

It would depend on the types of MIDI messages that were being sent. In any case, you should certainly make sure that the SAM is on the 'off' state prior to auto-detecting, so that the 'on' event gets head, followed by the 'off' event, before clicking the 'Done' button. (If only one of the two events was heard it may get configured to toggle the virtual stop, which might cause issues with SAMs.)

Since the Midi Boutique product connects via the old 5-pin MIDI cables it would be advisable to go to General Settings->General Preferences->Advanced Preferences and tick the box "Limit MIDI Out Send Rate to MIDI 1.0 baud".

It's also possible that some or all of the SAMs are wired backwards on the decoder or that the decoder is not operating in Mode 1. What I would consider normal is that the SAM closes a contact to ground, usually the grounded frame of the SAM, so that moving the tab down or pulling the drawknob would generate a contact closure and a NoteOn from the decoder to HW. If the power supply ground does not connect to the frames of the SAMs then incorrect operation is almost certain. I don't recall if the Midi Boutique encoders can be set for reverse voltage inputs but suspect that they cannot as a positive voltage on the frames would be much larger than the 3.3v or 5v that the decoder would be using.

The decoder in this case would be a high-side switch providing a voltage to one of the two SAMs coils. Switching the opposite way by providing a ground to one of the coils would be a low-side switch and problematic in the case of normal SAMs.

My situation is now: input of the registers: (BBS1K encoder Midi-Hardware.com where the stops with reed contacts are on left midi channel 12 and right BBS1K encoder midi channel 13 both on the mrg2 midicontroller with midi merge on)
Output of the registers MDDP128 left midi channel 12 and second MDDP 128 right midi channel 13.
The midi input 0001 of the Emu1616M set on Midi channel 12 and 13.
The midi output 0002 of the Emu1616M set on Midi channel 12 and 13.

So the output 0002 which contains the MDDP128 decoders is not linked back to midi in and is therefore a separate midi output. Always suppress already checked at the output in HW because otherwise the registers went back and forth very quickly (fluttering).
Previously there was no matching and then half the labels went on and off at the start of the SSC.
Martin Dyde advised me to take care of matching midichannels and notenumbers but that did not solve the problem.
I also soldered suppression diodes between the coils on the stopboards everywhere. Did not help either.
Then I made sure that no loop could be created by putting the MDDP128 decoders on a separate output and no feedback to midi in.
That did not solve the problem either.
So where is the problem?
It is also strange that some labels light up while others do not while starting the sample in HW.
Also by general crescendo back to zero some stops keep in on stage.
It could also be the MRG2 midi controller which sends the on/off messages.
If so, I could still connect the two BBS1K encoders to the 2nd MRG2 which is in the midi merge off position. Just like the thumb and foot pistons. I will try that.
But whether that will help...
I also expect that the MDDP128 control board sends all incoming midi signals back somehow as say in the manual:
The incomming midi signals from the MDDP128 will get also a return back.

Also when a record midifile is played in HW half of the stops come out and go in before the recordered registration wil come.
So Hw sends first note on and note off messages to electric stops. Why not alone note off??

[mdyde]

Hello musicman1958,

(I assume you're working with Drew on the same console, given that you posted it in this thread of his.)

Martin Dyde advised me to take care of matching midichannels and notenumbers but that did not solve the problem.

Just to clarify: the reason for using the same MIDI channel and note (or NRPN) numbers for input as for output is that it means you can simply auto-detect stops, instead of needing to configure their MIDI output settings individually. It wouldn't make any difference to MIDI behaviour once configured.

My only suggestions to add to previous ones that have already been made in this thread (avoiding the MIDI encoder echoing state changes back, etc.) would be:

- When testing, use the St. Anne's sample set since it's small, simple, and everybody has ready access to it, and configure just a few of its stops for testing purposes (clear MIDI settings for all others if you'd already configured them), so that it's easy to keep track of their events in logs.

- Try auto-detecting those (few) stops again, making sure that for each Hauptwerk hears the SAM's 'on' event first, and then its 'off' event, before your click the Done button. (If it only heard one, you would get toggling behaviour, which could lead to unintended results.)

- Try turning on the MIDI logging option on the 'General settings | General preferences | Advanced ... ' screen tab. You will then be able to see the exact MIDI events that Hauptwerk is receiving, what virtual controls they triggered, and what MIDI output was sent from those stops. (Use 'Help | View activity log' to see the events.)

Also when a record midifile is played in HW half of the stops come out and go in before the recordered registration wil come.
So Hw sends first note on and note off messages to electric stops. Why not alone note off??

When a MIDI file starts to play, Hauptwerk will simply turn off all virtual stops, which will cause them to send (only) an 'off' event. It won't turn them on. If they're getting turned on somehow then your MIDI SAMs must be causing that, e.g. by sending note-on events to Hauptwerk in response to the MIDI note-off message that Hauptwerk is sending to the SAM.

If you need help with diagnosing why that's happening I'll have to leave that to others, since I don't myself have first-hand experience of the MIDI encoder/decoder boards you're using, or of wiring up SAMs.

I'm using older MidiBoutique decoders and was experiencing similar issues early on.

The first thing I tried was to lengthen the pulses going to the On/Off coils which made a significant difference. I've settled on 300ms pulses.

I went a couple of years until discovering and ticking "Always suppress output (echo) if direct response to input" and this took care of the occasional glitching I was experiencing.

The only other things that might be worth mentioning is being sure the coil power supply has enough excess capacity that it won't sag when loaded and that the wiring be sufficiently heavy. I suspect you are very well aware of these sorts of things.

Thanks, everyone!

I am slowly working through everyone's comments. Keep them coming!

I am slowly chipping away at it getting things better and better. As suggested, it's a combination of issues, for sure.

I am thinking its a BARELY adequate power supply - 55amp, with 120 SAMs at .4amps each. So, I ordered a 100amp power supply today. Let's solve that.

I'm also going to redo some of the "bus" wiring. Rather than a couple (4) large busses for all those tabs, I will break them up even more.

I did find one small short that I think was contributing to most of the fluttering - it now only seems to be happening in a small few stops - I will investigate more tomorrow. Maybe I have another small wire lightly touching something it shouldn't. (That's what happened in the one short I found - upon close inspection, a "stray hair" was ever so gently touching the next solder pad over.

I also messed with the timing settings in the mddp128, with mixed results. Sometimes it appeared to work better, but other times not so much.

The one thing that IS CONSISTENT NOW, is that GENERAL CANCEL does a pretty good job of cancelling EVERYTHING, but a piston set to basically turn EVERYTHING ON, never seems to work well. And it tends to be the same few SAMs that are always the troublesome ones.. So I wonder if this means the power supply is sufficient? General Cancel cancels everything MOST OF THE TIME. Would this then indicate a MIDI timing/sync/baud rate issue, it having trouble decoding all of those incoming note on messages?

Thanks again, folks. I will keep going through your suggestions as soon as I can.

On the matter of power supplies, It has often occurred to me (as a theoretical matter - I don't use electromechanical stops myself) that most of the time there is no power requirement at all for the SAMs, it's just that large and simultaneous registration changes make very heavy demands on the current available. For this reason, I've often though it possible that large capacitors (or even a rechargeable battery) might be sufficient to supply the short term current need without using a large power supply which does virtually nothing a lot of the time.

Never tried it - just a thought.

Nick

On the matter of power supplies, It has often occurred to me (as a theoretical matter - I don't use electromechanical stops myself) that most of the time there is no power requirement at all for the SAMs, it's just that large and simultaneous registration changes make very heavy demands on the current available. For this reason, I've often though it possible that large capacitors (or even a rechargeable battery) might be sufficient to supply the short term current need without using a large power supply which does virtually nothing a lot of the time.

Never tried it - just a thought.

Nick

Yes, I’ve known of a few examples to use batteries with a trickle charger attached. That said, however, I am no expert on the subject and have no personal experience doing that.

Regarding timing, I am using 8 (5 input, 3 output) 60' MIDI Din cables which are 10' longer than the standard allows. They plug into a Motu MIDI Express128 and it is a USB bus powered unit. I have not limited the BAUD rate in HW and the buffer is set to 1024 The 3rd MIDI Out cable handles the HW Status data that I'm using for a custom display. So all in all, there can be quite a bit of traffic.

This system has performed without flaw after resolving the initial problems I outlined above.

Because of the way I've implemented things, the 136 SAMS do not switch simultaneously. The virtual stops respond instantly and simultaneously but the SAMS, in groups of up to 32, lag behind a smidge and you can see a quick wave of motion move across the console when many SAMS switch state. This does not affect my playing except that I have to be careful to not press a button or toe stud too early.

My install had less than 96 stops so there were three 32 stop modules rather than the four that others have connected. While I daisy chained the two main boards and connected them to a Yamaha UX-16 USB interface, if there were traffic issues I would have connected the two boards separately, using two of the UX-16s.

This was my only install using the Midi Boutique decoder due to a time constraint. I've done many Allen organs and a Moller capture system using my own decoder designs. With my hardware I use a 60ms pulse and I recall using 90ms with the Rodgers SAMs and the Midi Boutique decoders. The Allen SAMs operate at 45 to 50v while the Rodgers were a more normal 16v.

For power supplies I converted two existing Rodgers power supplies from -16 to +16v. The Rodgers 32C had one dedicated -16v supply while the main power supply also had a -16v section feeding some of the SAMs. I don't recall the current capacity from both supplies but it would be whatever is in the 32C service manual.