I’m using MagicSpoutSender v2.003 in Magic 2.5 under Windows 11.
I’m feeding the output of a Text module into the MagicSpoutSender, sender name “MagicSpout Sender 1”, which feeds the Magic output module.
All behaves as expected and I can see the text in the demo Spout Receiver when “MagicSpoutSender 1” is selected.
If I then also feed a Starfield module in to a lower input on the Magic output I would expect that only to be visible in the Magic Main Sender Spout output, but I also see it sent by the MagicSpoutSender - to which the Starfield is not connected.
Many thanks for the MagicSpoutSender, but I cannot understand this behaviour.
Sorry, no screenshot - for some reason I cannot upload an image.
I assume you want the text to be part of the main output. Otherwise, the text module does not need to be connected to the Magic Main window if you just want that as a separate sender.
But yes I can reproduce this if the text module is connected to the upper input of the Magic window and the starfield module is connected to the middle input. In that case, “MagicSpoutSender 1” shows both the starfield and the text in a receiver.
But if the inputs are reversed so that the starfield is connected to the upper and text module to the middle, it works as expected. That is “MagicSpoutSender 1” shows only the text in a receiver.
It must be something to do with the multiple inputs to the Magic main window but I do not know the cause and I regret that I can’t offer an explanation. Hopefully reversing the inputs will achieve what you require.
After a little more investigation I found that the problem only shows if the input to the MagicSpoutSender has some transparency.
My very strong personal preference is to maintain a logical connection order to the Magic module, avoiding need to change the project if a subseqent Magic update fixes the current anomalous behaviour.
As an inelegant workaround in this test case was stripping the transparency from the input to the MagicSpoutSender (simple with a solid black input to a lower input to the module), restoring the transparency of the text to the Magic module with Lumakey on the output of the MagicSpoutSender, and likewise restoring transparency at the receiving end(s) of the MagicSpoutSender with Lumakey.
For intermediate levels of alpha in a MagicSpoutSender source signal the alpha could be “cloned” and imposed on the feed to the Magic module, but an additional Spout sender would be needed to carry an alpha key.
Thanks again - it’s great to know there’s such responsive support for the
I had a look at this and there is the option “Window > Magic Window Options > Send Alpha Channel”. But that applies to the main Spout output and I can’t find any way of changing the input transparency within the module itself. As far as I can tell the module output background is always transparent (alpha zero).
At least the workaround gets you going.
Update
I found an omission in the module code. The sender was not released if the module was removed. I added that, rebuilt with the latest SpoutGL files and made a new release 2.004.
Thanks for the new version. To be honest I couldn’t see any difference in the behaviour - both versions seemed to terminate when I exited the host Magic app.
I was puzzled by which output was referenced in your comment "As far as I can tell the module output background is always transparent (alpha zero) "
I’d never thought to look at a MagicSpoutSender’s Spout output when it had no input, its Spout output always had full RGBA handling and the module itself passed RGBA through unaltered. Out of interest I decided to investigate.
I have a diagnostic Magic Scene Module that splits RGBA into four quadrants. I put an instance of this into a SpoutReceiver project and confirmed full RGBA Spout reception.
I then used the diagnostic in the MagicSpoutSender project to examine the module’s output, leaving the MagicSpoutSender and Starfield connected to the Magic module as before.
Even odder behaviour of the Spout stream. Each of the quadrants of my RGBA display randomly and individually (asynchronously) flashed the starfield. Adding Spout receivers behaved likewise - individually they flashed the starfield. It appeared that the starfield could only be seen on one of the Spout receivers at a time (and sometimes on none).
No you probably won’t notice any difference. The problem occurred when there was Magic Spout output as well, and the sender module was removed while leaving Magic open. In that case the sender module name remained. It was released OK when Magic itself was ended. It was a bug. The NDI modules are OK.
This is complicated. I did some testing too and I hope you can follow it.
I can tell if a sender background is transparent or opaque in a new version of the Demo receiver that I have not released yet. The module sends what is connected to the input. For example, if I start with the Magic main Spout output off and connect the text module to the input of the sender module, the Magic window shows a black background but the background parts in my receiver are transparent. It is the text module that is producing the transparent background. The sender module just passes it through.
But the main Magic Spout output affects the sender module as well. If I set the main Spout output on and the option “Send Alpha Channel” is off, the background parts are opaque black in my receiver for both the main output and the sender module. That is, the Spout output produces alpha one (opaque).
If the option “Send Alpha Channel” is set on, the background parts are transparent in my receiver for both the main output and the sender module. That is, the alpha channel of the Text module is sent through unchanged and produces alpha zero (transparent).
If the main Magic Spout output is off, the option “Send Alpha Channel” has no effect. The alpha channel of the sender module cannot be forced to be opaque. It passes through what is connected to the input.
So the question is, would the problem be solved if the sender module had an option like the main Spout output “Send Alpha Channel”. This is not a simple change but the NDI modules have the basis for doing it.
In my ignorance of the internals of either Spout or Magic my intuition is unreliable, but it seems to me that an option not to send alpha in the MagicSpoutSender is just a convenient mask for the underlying interaction issues in the Magic environment.
It’s a simple matter not to send alpha into the MagicSpoutSender if it causes issues.
No need to change the sender, just the source fed to it. Perhaps worth documenting the issue and discussing with the Magic Devs.
If I had a alpha-handling wishlist for the sender it would be to add option to send alpha in the RGB as a key. This would pair nicely with a second sender set to send just RGB with alpha 1.
Yes from my testing it appears that there is interaction of Magic Windows settings and the modules. The option for “Send Alpha Channel” when “Spout Output” is selected over-rides setting alpha of the module output.
Meanwhile as far as I can tell, the text module produces transparent alpha for the black background but the text itself is opaque. If you have difficulty with it, perhaps you could bring it up on the Magic user forum.
Setting the alpha value as a key might be an idea but my initial thoughts are that this is outside the scope of the module MDK.
I did bring this up in the Magic forum. An edited version of Magic’s response follows:
“We don’t develop or support that module at all… it’s entirely done by Leadedge.”
“If I recall, this is one of the reasons we don’t have a standalone sender module. I think we had it at some point, but there were certain issues that could not be overcome.”
I just need to workaround the issues. They think they had them too and could not fix!
Many thanks for your all your support anyway - at least I know there’s no currently feasible solution.
I must have missed that one. Yes the additional sender module is not supported by Magic and the program is not designed for it.
I am reviewing the NDI modules at the moment and realized that the first option I suggested, to put the sender module input as the bottom input to the Magic window, is in fact the correct way to do it. Have a look at the Magic User’s Guide and the section “Editor > Ordering Modules”. There it says :
The top-to-bottom order of connectors is important, because it determines what module is drawn first, and therefore in front of, the other modules. The top connector and input pin always represent the top layer of drawing, and each subsequent connector and input pin represent the next layer underneath.
That is, bottom layers are drawn first and top layers are drawn last.
What the sender module works with is not the input pin directly but rather the current frame buffer, which includes whatever source is at the input pin. So if it is connected to the topmost Window input, all the layers below add to the frame buffer, in this case the Starfield. If it is connected to the bottom pin, there is nothing rendered previously and the current frame buffer contains only the input source, in this case the text module.
So it seems to me that changing the order of the modules connected to the Window is an entirely valid thing to do. Please let me know what you think.
The option “Window > Send Alpha Channel” affects the sender module output if “Window > Spout Ouput” is selected, otherwise the transparent background of the text module is passed through. It is possible to add an option to the sender module to send opaque or transparent alpha independently but that could become confusing.
Ah, I had assumed that the MagicSpoutSender would be sending its input pin signal. Your explanation that it sends the frame in the Magic buffer when its output pin signal is rendered resolves all the mystery.
Without this knowledge the behaviour is counterintuitive, but now makes perfect sense.
I guess the alpha interaction with Magic’s Spout setting might be related. Knowing the issue suggest a workaround though - send alpha as an RGB key in an additional MagicSpoutSender placed above the first with its alpha always 1.
I can easily do all the alpha manipulation in an ISF I made. My guess is that anyone actually sending and using an alpha channel would do likewise.
Another thing I want to think further about is keeping MagicSpoutSenders alive regardless of which scene is currently active. With the knowledge of how to connect the MagicSpoutSender(s) I should be able to add these to the PostProcessor scene with a RGBA=0 connection above them in the Magic module.
Once I have time to try all this I could usefully write it up in a Magic tutorial.
Very many thanks for all your help, insight and inspiration!
Yes it’s all in the User Guide but needs some insight to understand it with respect to a module. A tutorial would be good.
I think that “Spout Output” and “Send Alpha Channel” are applied at the end of the chain to the current frame buffer and so all modules, including the one at the beginning of the chain would be affected. The NDI modules might be affected too. I am looking at those at the moment.
Each MagicSpoutSender should stay open regardless of the scene change. But if there is no rendering for a scene, the output might be black. I will think more on that one.
