-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Peekofwar: Wiremod input for playlist URLs. #18
Comments
Oh yeah, that's right. Playlists have names associated with the file... Theoretically you could have a table that uses arrays where the table is the playlist, and the arrays each contain two values, but this could potentially be a little confusing...
Just a thought. Alternatively you could just have an array that resembles how the playlist files are made with each array entry being a name entry followed by an address...
Personally, I'd prefer the table of arrays. |
I'm not sure. The stuff needs to be kinda idiot proof and both seem not to be that well understandable to users. I like the first option more, but it is also less transparent. To be idiot proof it would need to support other formats as well, as like:
This seems kinda messy to implement. Wire inputs also don't have a way to tell users about the wrong format, so what should it do when the input is bad? Just ignore it? What happens on empty URLs and/or empty names? On case of the 2nd option, what would happen if the one name is skipped? How would you determinate if a line was a name or a path/URL without having to guess it? There is one idea I could work with: I will change the playlist output to have your first option as it's format, remove the name/URL separation on the playlist output. The new input will only support that format as well. So it works as output like input and users can see how it works. Invalid types or data would be skipped/ignored. Backwards compatibility for old dupes is not a thing I care about, it dies as soon as it gets in the way of development. |
Some additional thoughts: You could theoretically have two different playlist input options where the first is a Table with arrays, and theoretically you could check if either the second string is empty or doesn't exist and assume the first in the array is the address...
... and secondly, you could have an alternate array input that only accepts file addresses and doesn't support providing track names. Track names in this case could just default to the filename or file path.
Having two different input options could theoretically be confusing to users though... And what if the user hooks up both? In the case that a user connects valid input to both, perhaps the one that supports track names takes priority over the basic playlist array input.
I guess in most cases file addresses typically have a file extension at the end. However, it is possible for track names to contain punctuation which could potentially get detected as a file extension. If I'm not mistaken, Stream Radio also supports streams, which I'm not familiar with the address format of.
Theoretically the Stream Radio could show an error message that indicates the Wire input is malformed. |
I would prefer to not add complex bloat. It will be one input and one output for the playlist. I am not going to add unreliable/inaccurate name/address string detection. Maybe you see now, why it was not added yet. Coding a separate error screen for this is pain, so I would rather skip this and just make it skip/ignore malformed parts instead. Arrays with length <= 1 will assume URL at index [1], otherwise it is [1] for name and [2] for URL. (subject to change) Btw, address format is HTTP URLs or local file paths as told so in the stream URL description in the toolgun menu. |
@Peekofwar on Workshop:
In the most recent updates I changed the structure and handing of playlist data in the radio entity to separate it from the GUI elements, so non-display radios can use and store and playlist data too. This is needed to implement the playlist input.
There are some issues with this I would have to solve first:
Wire input #1
,Wire input #2
, ...,Wire input #N
, but this looks kinda lazy and maybe confusing to the user too.The text was updated successfully, but these errors were encountered: