Multiple, possibly related feature requests.

[zotz]

Some more closely related.

1. In rdairplay, have 3 radio buttons or another widget that can do the same job. depending on which button is selected, the matching log / log machine shows on the left where the main log always shows now.
2. All log machines to be virtual log machines. (I think this will make a lot of what follows easier.)
3. Have a drop down on the screen that will select which group of 3 consecutive virtual log machines will be displayed by rdairplay.
4. Log machines can be "loaded" and started without rdairplay running. via rml, this is how virtual logs work now.
5. rdairplay can be run and then attach to already running groups of virtual log machines or connect to a group that does not have logs loaded or run and then the rdaidplay interface can be used to load logs and otherwise control the virtual logs.
6. Each group of three virtual logs that can be loaded by rdairplay in this manner can be marked as related or independent. (Not sure if this is needed but it may make the use of the group cleared.)
7. This next on is related only in concept. Similar to the above, let rivendell start jack and multiple glasscoder instances and make needed connections. Then later, let glassgui attach to a running glasscoder and control it the way glassgui controls itself now.

all the best,

drew

[ElvishArtisan]

All good ideas, but will require a major rewrite of rdairplay(1) and its underlying infrastructure. Let's get a production version out of the door first.

[zotz]

I just wanted to document it.

I have had a further thought. It might be possible to create a sort of external "fake" rdairplay to do this for the virtual logs without making any changes to rdairplay at this time. I may play around with this if I get further in my v4 testing/learning.

drew

[alexolivan]

Hi guys.

Although aware that, right now, the single priority is to have v4 released... I would add, for the last point on that list (regarding glasscoder, glassgui...etc), that I had somehow similar thoughts in mind: The thing is that, while Rivendell has the podcast management feature nicelly integrated in the suite (which is a feature found on 'modern' top-of-the-line automation systems) it strangely lacks streaming integration, at all (something that puts it along 'old-school' automation systems) but, at the same time, there's enough related/companion software that can be used along (Glasscommander / Glassplayer) to do the task fairly well... So, the immediate follow-on though is: why do we have RDPodcastManager and not RDStreamManager, if a ton of the work is done?

On automation-systems I know being used here... streamings have become integral part of the radio ecosystem in the last years (along with podcasting). Not only streaming out to CDN, but streaming to share audio among radio stations. The system provides for scheduling of the streamings, sending the metadata, etc, etc... Also, and very importatntly, the streaming-in has also become an integral part, as hardware-based streaming decoders / satellite receivers have become a thing of the past (at least in Spain and some other european countries). I see a ton of potential in all that collection of tools (Glasscommander, glassplayer, etc...) to add to the Rivendell Suite a set of features in the line of 'modern' automation systems.

Cheers!

[ltyndale]

Ultimately it is up to Fred, however I would not want to see streaming added to the suite, in my view it is better left for an external application.

For streaming it is easy enough to just start up the streaming application of your choice and have Jack route all the audio as needed.
Adding it into the suite would just make things more complex in my view.

As it is now, it is possible to have Rivendell automatically start a streaming app via the Jack setup. You can have Rivendell start up any Jack application after Jack is started which could include something like GlassCoder.

Lorne Tyndale

On 2023-05-30 04:22, Alejandro Olivan Alvarez wrote:

Hi guys.

Although aware that, right now, the single priority is to have v4 released... I would add, for the last point on that list (regarding glasscoder, glassgui...etc), that I had somehow similar thoughts in mind: The thing is that, while Rivendell has the podcast management feature nicelly integrated in the suite (which is a feature found on 'modern' top-of-the-line automation systems) it strangely lacks streaming integration, at all (something that puts it along 'old-school' automation systems) but, at the same time, there's enough related/companion software that can be used along (Glasscommander / Glassplayer) to do the task fairly well... So, the immediate follow-on though is: why do we have RDPodcastManager and not RDStreamManager, if a ton of the work is done?

On automation-systems I know being used here... streamings have become integral part of the radio ecosystem in the last years (along with podcasting). Not only streaming out to CDN, but streaming to share audio among radio stations. The system provides for scheduling of the streamings, sending the metadata, etc, etc... Also, and very importatntly, the streaming-in has also become an integral part, as hardware-based streaming decoders / satellite receivers have become a thing of the past (at least in Spain and some other european countries). I see a ton of potential in all that collection of tools (Glasscommander, glassplayer, etc...) to add to the Rivendell Suite a set of features in the line of 'modern' automation systems.

Cheers!

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Links:

[1] https://github.com/ElvishArtisan/rivendell/issues/887#issuecomment-1567986589 [2] https://github.com/notifications/unsubscribe-auth/AC5JEH6PEHDJGADDY7SDAKDXIWU5ZANCNFSM6AAAAAAYS7KPKQ

[zotz]

All good ideas, but will require a major rewrite of rdairplay(1) and its underlying infrastructure. Let's get a production version out of the door first.

No need to rush.

In the meantime, I have started this recently:

rdnairplay or rivnairplay

If you test this, try the pysimplegui version. It is further along and may be the way forward.

I am trying to see how much of this request I can accomplish from the outside. With mysql read only. With the apis, rml, etc.

If that can not get me far enough, then I am wondering what is the minimum code changes that could get me mostly there.

I think that, for certain use cases, what I have working already will be useful to me and perhaps to others.

I also think the effort and what I learn in the process might help me to refine the request.

If I am seeing what I think I am, right now, for standalone, auto refresh logs, if you monitor a log with what I have and make any live changes to it with rdlogedit, you should see what is happening. (You just need to save the changed log and then exit and restart either my whole thing or at least stop watching the log and start watching it again.)

This is not battle tested at this point. Feedback welcome.

If you know of a way to get a currently loaded / playing log's (log machine's) status after changes have been made in the normal rdairplay interface or with rml send commands, I would love to learn how.