add preference option for geo-assets vs timed-assets

[hburgund]

Currently, the timed-assets take precedence over the geo-assets in the playlist. It would be very nice to have the option to have it the other way around. I've got a project right now that has more timed-assets than geo-assets, so whenever a geo one is available, I want to make sure it gets played.

This is a project-level consideration, so it would likely make the most sense to add a config option in the project model; something like project.asset_preference?

Here's the code that handles the ordering, I believe:

https://github.com/roundware/roundware-server/blob/7a4843864f73ae17261d90065d106c4878d8e011/roundwared/recording_collection.py#L122

Should be pretty easy to add a conditional of sorts using a lookup to the new project field. Or maybe there's another better option altogether?

[13rac1]

A toggle on the project model seems fine. project.timed_asset_priority? project.geo_asset_priority? OH WAIT audiotrack.timed_asset_priority! You'll absolutely want it audio track specific. :grinning:

[hburgund]

I have confirmed that changing the order of playlist updating and moving the timed asset updates until after the proximity asset updates does, not surprisingly, cause proximity assets to take precedence. Here's the code in recording_collection.py that is moved down about 15 lines do accomplish this:

self._update_playlist_timed()

        if len(self.playlist_timed) > 0:
            return self.playlist_timed.pop()

This is just a crude proof of concept; I need to make it a choice by adding a config option still, but I'm not decided on whether it should be a project-level config or an audiotrack-level config.

@eosrei can you explain why you think audiotrack is a better place? I can definitely see that approach providing more flexibility, but since there is only one playlist that is drawn on by all audiotracks, making this an audiotrack-level option seems like it would require some more substantial changes which might not be worth it considering practically, I don't think having audiotracks set differently within a project is going to be something I'd want to use all that often...but hard to tell. You have vastly better insight into the code, so let me know what you think.

[13rac1]

Hmm... I wish you'd asked for more details on oh... April 7th. Haha! I knew the exact reason I thought that then. I'll figure out the reason and let you know.

[hburgund]

Ack!! Sorry about that...we did have a discussion in chat about this, I now remember. I dug it up to jog our memories:

---

Halsey Burgund ah, per audiotrack preference...that would allow for even more flexibility...cool! I assume that works sensibly with the way audiotracks and playlists are constructed?! Brad Erickson codewise.. I think so but logic wise.. I think its better I was thinking about it. and realized its actually an audio track option might be slightly more complex to implement.. but in terms of functionality, its ideal doesnt matter which is option "has priority" you can pick either one but its good IMO to make it a true/false yes/no statement Halsey Burgund we only have one playlist that both audiotracks choose from, yes? or am I confused? Brad Erickson currently yes. So.... I think youve just figured out a bug. If you have two audio tracks, then theyll both grab from the playlist and double audio is possible so.. really. you want to make it so that only one uses the timed playlist. OR... make assets playable on only one audio track Halsey Burgund it seems to work properly now with both audiotracks pulling from the same playlist and removing their items when done playing, so no repeats. Brad Erickson ... idk.. lots of options.. gotta think how you want it to work, and how it would make sense Halsey Burgund but maybe moving forward, each audotrack should have it’s own playlist? that would facilitate the whole tag filtering of audiotracks

---

I should add that the initial reason to have multiple audiotracks possible is to allow for some controlled overlapping of audio assets. This is a desired feature, not something to avoid. I'm not sure if when you refer to "double audio" as a bug above, you mean overlapping or repeated...

[13rac1]

I should add that the initial reason to have multiple audiotracks possible is to allow for some controlled overlapping of audio assets. This is a desired feature, not something to avoid. I'm not sure if when you refer to "double audio" as a bug above, you mean overlapping or repeated...

Overlapping audio is totally reasonable if only one audio track plays human voice. It needs to be VERY carefully handled. Unless you are timing everything perfectly such as in a Round (http://en.wikipedia.org/wiki/Round_%28music%29) people IMHO :tongue: will interpret two human voices speaking at the same time as an error.

I have confirmed that changing the order of playlist updating and moving the timed asset updates until after the proximity asset updates does,

Yes. That will never change which is selected. You must change the code where they are chosen.

maybe moving forward, each audotrack should have it’s own playlist? that would facilitate the whole tag filtering of audiotracks

This makes sense to me.

can you explain why you think audiotrack is a better place?

Yes. If the option is audiotrack.timed_asset_priority, then the complete question is: "Should the audio track prioritize assets from the timed asset playlist?" If the option is project.timed_asset_priority, then the complete question is: "Should all audio tracks in the project prioritize assets from the timed asset playlist?" After looking at the code, I see project-wide is far more easy to implement; just needs a few lines changed in recording_collection._get_recording().

[hburgund]

Ah, you so easily forget that Roundware was built as an aesthetic tool for creating sound art... ;-) The potential for overlapping voices is crucial for me and the core mission of Roundware, but of course, I appreciate that other users may not want that, hence the audiotrack design which allows for a plethora of different possibilities.

For current needs, being able to answer the question "Should all audio tracks in the project prioritize assets from the timed asset playlist?" is totally adequate and since that change is significantly easier to make in the code, perhaps I do that now and then if/when we decide to split out playlists per audiotrack and get into filtering per audiotrack etc, we can move the functionality to the audiotrack level?

I realize moving it isn't ideal, but I don't see the re-architecting of playlists etc as being something that is likely to get done anytime soon, so this may be the way to go for now. I guess the other option would be manual changes on different installs to handle the different projects, but that doesn't sound like a great idea :-/...

[13rac1]

Ah, you so easily forget that Roundware was built as an aesthetic tool for creating sound art.

I don't forget that! :P I must advocate for the users who aren't you. Most people will not want two audio voice tracks playing at the same time. I would, if I didn't know all about the audio art installation beforehand, consider it broken. I cannot focus on two audio voices at the same time, so it's random frustrating noise. Basically, we need to be careful to make sure it's never accidentally enabled.

I guess the other option would be manual changes on different installs to handle the different projects, but that doesn't sound like a great idea :-/...

Correct. Don't do that. Make this an option on the project: timed_asset_priority it's simple to implement in recording_collection

[hburgund]

I think there are reasonable safeguards in place about not having multiple voices playing at the same time in that you have to actively create more than one audiotrack to have that happen. Documentation will be crucial and should no doubt be updated to make this totally clear. The default database only has one audiotrack, so if people use it as an example, they should be OK. Maybe implementing #231 would help simply by enforcing the idea that audiotracks are enabled by a specific admin action?

I will go ahead and make the project.timed_asset_priority boolean setting and wire it up in recording_collection. Shouldn't be too hard, but you'll be able to review my pull request to make sure I haven't done anything wacko. I will branch this off of my outstanding pull request just to not have to mess around with the sequence of migrations.

[13rac1]

Sounds great. I'll look at that other pull soon

[hburgund]

fixed by https://github.com/roundware/roundware-server/commit/e1c935d45d8845b8778b144ac6a6c1a481e83e28