Switch between two sound devices for encoder

Hi,

I’d like to have a script perform these steps:

    1. fade out automation
    1. deactivate a VST plug-in
    1. switch the sound device used for the encoder
    1. start automation playback

My guess is that 2. and 3. aren’t possible to implement through the scripting engine yet?

Background:
I would like to run a 24/7 programme from one computer that is connected to a mixer. Only live shows are supposed to use the mixer input though, for the unattended programme mAirList is supposed to take the input directly from the (another) soundcard (monitor). The sound taken from the monitor channel should be processed by a plug-in before going on air, the live sound is already processed (that’s why the plug-in needs to be activated/deactivated).

Any help appreciated :smiley:

Marcus

Not a big deal, except #2, for which we need a trick, which I haven’t tested but which should work fine - just try out for yourself:

Plugins cannot be deactivated, but you can change their priority in the processing chain. The higher the priority value, the earlier the signal is routed through the plugin. The encoder process is treated like a DSP plugin as well, with a priority of -1000, so all “real” plugins are processed before the encoder. However, when you set the priority of a plugin to a number less than -1000, say -2000, the signal goes first through the encoder and then through the plugin, so the effect of the plugin is not heard, although it’s still running.

Here’s the complete script:

begin
  CurrentPlaylist.AutomationStop;
  Encoder.GetDSPPlugins.GetItem(0).SetPriority(-2000);
  Encoder.SetPlaybackDevice(0);
  CurrentPlaylist.AutomationPlay;
end.

For the playback device, 0 means “no local output”, 1 is the first device in the list, and so on.

Note that this script requires the latest snapshot, build 968, which I’m uploading right now.

Thanks for your immediate help!

As for SetPlaybackDevice — That’s just the Playback device though, isn’t it – for local playback? I’d need to change what’s labeled “Record Device” in the control panel though – as that’s the device the encoder takes as its input – correct?

Having the plug-in running all the time means it consumes CPU cycles while not actually being used, so that’s not exactly a good thing — but I could live with that little downside if the rest of the script worked.

Thanks,

Marcus

Okay, there’s a procedure SetRecordDevice, which I guess should work for that.

When I do this manually, I need to stop Live mode and start it again, for the changes to take effect. Is that also the case when performing this action via a script?

Also, is there a way to find out which device number is assigned to what device? (for the encoder)?

Thanks again,

Marcus

Enable live feed: Encoder.SetLiveFeedEnabled(true);
Disable live feed: Encoder.SetLiveFeedEnabled(false);

For the device numbers, it’s in the same order as in the selection list. For recording, 0 is the first device, 1 the second and so on.

Brilliant.

About to test this now… will report back :slight_smile:

Well, after some extensive testing, here’s the result:

It doesn’t work :frowning:

I’m using 2 scripts:

switch_live.mls = switches to mixer input (record device 3)

begin CurrentPlaylist.AutomationStop; Encoder.SetLiveFeedEnabled(false); Encoder.GetDSPPlugins.GetItem(0).SetPriority(-2000); // dsp plug-in not needed as input is already processed Encoder.SetRecordDevice(3); // 2nd soundcard, takes input from mixer Encoder.SetLiveFeedEnabled(true); CurrentPlaylist.AutomationPlay; end.

switch_auto.mls = switches to soundcard monitor input (record device 4)

begin CurrentPlaylist.AutomationStop; Encoder.SetLiveFeedEnabled(false); Encoder.GetDSPPlugins.GetItem(0).SetPriority(1); // dsp plug-in needed as input taken from soundcard requires processing Encoder.SetRecordDevice(4); // 1st soundcard's monitor mix channel Encoder.SetLiveFeedEnabled(true); CurrentPlaylist.AutomationPlay; end.

This is how to reproduce the behavior…

I start mAirList and run the second script to use the soundcard input. Automation starts playing, everything running as expected.

I run the first script to switch to the live input. This works as well.

I run the second script again to switch back to the soundcard input. This time it doesn’t work. mAirList continues to take the input signal from the mixer signal, even though the Control Panel within mAirList shows the the source has changed back to the soundcard monitor mix channel.

Even when I switch devices manually, and then deactivate and reactivate the live feed, the encoder takes the input from the mixer.

Only restarting mAirList fixes this and enables me to use the soundcard’s monitor mix input again.

(Well, when the script runs, it doesn’t fade out the automation but stops abruptly — I guess this is an expected behaviour?)

Any ideas, Torben?!

Thanks! :slight_smile:

Marcus

Hm. Really strange. I think I have to try to reproduce this. Does the switch work when you use the Control Panel in the first place?

Regarding the “fade or not” question, I assume that you only use a single player in automation mode (have the option “only use a single player in automation mode” set). If so, when the final call to AutomationPlay is processed, the automation finds that the player is busy - with the fading item in it - and kicks the item out of the player, stopping it abruptly.

I propose that you remove the call to AutomationStop, and change the final AutomationPlay call to AutomationNext. It will have the same effect (fading current item, starting next one), but AutomationNext has a special handling so that the previous item continues to fade in the background, even if the player is now used for the new item.

As I recall it only works once, from monitor to live, but not back (when done manually through the control panel, and also when done via the script).

(I’m using 3 players on 3 channels on the mixer, one player for the cart wall and one channel for PFL = 5 separate outputs. Soundcards being the M-Audio Delta 1010LT and the Behringer DX 2000 USB internal one – Will try your proposed solution for the fade out problem, thanks!)

Is the problem symmetric, that is, when you set the input to Monitor in the config, and then try to switch it to Live using the script (or control panel), does the same thing happen? Does it stick with live then? Or will it always be stuck in the monitor setting?

Testing all kinds of scenarios now.

Manual changes, no scripts involved:

#1 - Start mAirList with live set via Configuration utility

  • Load Playlist, Play…
  • Stop automation
  • Open Control Panel within mAirList, change encoder source to monitor (other soundcard)
  • Start automation playback

Result: While the Record Device setting shows “Monitor”, the encoder is still taking the signal from the live input. This is expected as I didn’t stop/start the live feed… Next—

#2 - Disable/Enable Live Feed after changing device

  • Load Playlist, Play…
  • Stop automation
  • Open Control Panel within mAirList, change encoder source to monitor (other soundcard)
  • Stop/Activate live feed
  • Start automation playback

Result: Input is taken from the monitor channel (expected behaviour)

#3 - From #2 --> change back to Live input

  • Stop automation playback
  • Open Control Panel within mAirList, change encoder source to live
  • Stop/Activate live feed
  • Start automation playback

Result: Input still comes from monitor, although the control panel shows the live input

Tried the same sequence the other way round, starting mAirList with monitor input as standard, then changing to live and back to monitor. It’s stuck on live in this case, and I’m unable to change it back to monitor without restarting mAirList.

Hope my feedback is helpful. To avoid any problems caused by a plug-in, I have removed all plug-ins for testing by the way, it does however not change the results.

Marcus

I think you found a bug. And I found the fix :wink: Can you please try the new snapshot #970?

Tried it several times now, back and forth— and it’s working like a charm now. Thanks!

While mAirList switches the recording device, it hangs for about 2 seconds, resulting in a gap/stuttering on the Icecast stream. For now I’m manually fading out the running player (until there is silence), then switch the device, and start the next player. That results in a small gap, but it’s acceptable!

The only thing that bothers me now is the plug-in running in the background, using up precious CPU cycles – for a later revision, maybe you could implement an option to activate and deactivate a plug-in at runtime?

Anyway, I’m happy for now – so thanks again for your assistance.

Marcus

The delay is probably because the soundcard is initialized in the background, which can take some time depending on the hardware. Does the delay disappear when you switch the soundcard setting back and forth? Because I believe the old soundcard remains initialized when you switch over, and everything might be faster when you switch back to it. I’m not sure about that though.

Anyway, regarding the plugin, I have just uploaded another snapshot, build 971. There are two methods for the IBassDSPPlugin interface now: Detach and Reattach. (Actually only the latter is new in this built.

To detach the plugin from the chain, you can just write

Encoder.GetDSPPlugins.GetItem(0).Detach;

And to plug it in again:

Encoder.GetDSPPlugins.GetItem(0).Reattach;

You get no visual feedback about that in the control panel though. I will consider adding on/off checkboxes in the plugin list (just like we already have for databases, log interfaces etc.) which can also be toggled from a script. But for the moment, the above method should just work fine if you know what you’re doing.

Well… the gap’s there, and it doesn’t go any faster no matter how many times the same devices get initialized. HOWEVER, apparently detaching/re-attaching the plug-in is faster than changing its priority – it does run faster now!
Strangely though, .AutomationStop does behave differently now. It sounds as if the active player fades out, while the next one starts almost instantly. ‘Feels like’ the automation next button. It doesn’t bother me, but I wonder what triggered this… I did not change anything in the script other than commenting out the .SetPriority line and replacing it with the .Detach/.Reattach calls.

Thank you so much for all your efforts— I really appreciate it. You made me ditch SAM4, which I considered as an alternative for the automated programme— but mAirList is much more reliable, more responsive and simply ‘feels’ better!

Thanks again!

Marcus