Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Scripting Language for FB2K (Read 6923 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Scripting Language for FB2K

Given that:

(a) there are countless situations in which scripts that can control the player, deliver information about the state of various settings, components, or whatnot, or whatever would be useful and

(b) the developers' repeated insistence that titleformatting is not suitable for this sort of thing (and quite right too, for all that it's horribly inconvenient at the moment, since titleformatting is presently the only game in town) and

© 'Learn C++' is a bit of overkill if all you want is a button to, for example, toggle the playback order and

(d) Each of the customizeable components (the various playlists and track info panels, the panel stack splitter, Columns UI itself) has its own distinct syntax for presenting things,

it seems that a common scripting language for Foobar 2000, one that *is* meant for the things that titleformatting isn't, would be really valuable.

So what I'm wondering is, how easy or difficult would it be to implement something like this? Are we talking 'new component', '20 new components', 'new user interface', or 'may as well just write your own music player from scratch if you want this' levels of difficulty?

I'm not actually offering to do this; my own C++ skills are waaaaaay out of date, and while I would like to dust them off (and may use developing components as an excuse to do that), this sounds like a job for someone who actually halfway knows what they're doing. :) I just want to know if it's in the realm of pipe dream or slightly attainable dream.

Scripting Language for FB2K

Reply #1 –
The most important thing is missing here: A requirements specification. For which parts is the current titleformatting not suitable?

To speak for myself, I really wish that it was possible to control the playback flow based on tags, ie. which DSP preset is selected, settings on various DSPs, playback order, replaygain mode etc. based on certain rules.

fb2k already has a great design for this purpose, it just needs to be accepted and standardized.

I have no ideas which script language would be suited for this - Maybe the current formatting is actually good enough for this, but need another internal parser to avoid conflicts with display drawing? Another possibility is a more graphical configuration page, eliminating any scripting at all.

(Addendum) This is a great example of things that would be cool to be able for a programmer to create.Although I would like to be able (tag-wise) to define parts of a track that I want to skip.

For creating display panels, something more like HTML/XML with CSS seem more appropriate. I think there already were a thread proposing a standard with this in mind.
Can't wait for a HD-AAC encoder :P

Scripting Language for FB2K

Reply #2 –
Quote from: odyssey on
The most important thing is missing here: A requirements specification. For which parts is the current titleformatting not suitable?


Agreed, actually. My understanding is that titleformatting is primarily intended for access to information about a specific track, and nothing else.

I actually think that the general titleformatting syntax, with extensions like actual mathematical operators and conditional/script flow commands that aren't necessarily bound to functions, would be just about ideal. The problems with convoluted code can usually be traced back to one of these two things, not to the conventions of calling functions that start with $ or inserting the contents of fields or variables bounded by %% signs.

The other thing that's an interesting first stab in this direction is foo_scheduler. It really needs more options for its action lists to be a viable scripting system, but right now, with it, I can bind sequences like 'switch to this playlist, switch the playback order to random, and start playing' to a single command, and thus to a single button.

WSH panel is indeed another fine example of a good start; for those whom it works, it works fine, but it doesn't work for everyone. And it certainly needs to be better-documented. Still, the idea is sound, though it's not a total solution.

To whoever said that some sort of more graphical configuration would be desirable? I agree, that would be a thing of beauty. Not as a replacement for a scripting language, though; graphical systems will always be less precise, and sometimes you'll need to get at the nuts and bolts, but as a supplement or front end? That would be the ideal, I think.
 

Scripting Language for FB2K

Reply #3 –
Quote from: TomBarlow on
Quote from: odyssey on

The source is available. It would be great if a programmer took a look at this and it's possibilities. Also it really needs documentation.


Do you have a link? I mean I've tried looking at some C++ before and basically didn't understand any of it, but I'd love to have a go...

Here you go. foo_uie_wsh_panel 0.7.2

Quote from: DocBeard on
The other thing that's an interesting first stab in this direction is foo_scheduler. It really needs more options for its action lists to be a viable scripting system, but right now, with it, I can bind sequences like 'switch to this playlist, switch the playback order to random, and start playing' to a single command, and thus to a single button.

This is also my impression of foo_scheduler. I was dissapointed that I could not do more with it. But it has great possebilites.

Quote from: DocBeard on
To whoever said that some sort of more graphical configuration would be desirable? I agree, that would be a thing of beauty. Not as a replacement for a scripting language, though; graphical systems will always be less precise, and sometimes you'll need to get at the nuts and bolts, but as a supplement or front end? That would be the ideal, I think.

Actually I thought of the nice gui of foo_scheduler in the case above. It's not that I'm a big fan of GUI's, but it seem to be the approach that foobar authors prefer in 3rd part components.
Can't wait for a HD-AAC encoder :P

Scripting Language for FB2K

Reply #4 –
Quote from: DocBeard on
I actually think that the general titleformatting syntax, with extensions like actual mathematical operators and conditional/script flow commands that aren't necessarily bound to functions, would be just about ideal. The problems with convoluted code can usually be traced back to one of these two things, not to the conventions of calling functions that start with $ or inserting the contents of fields or variables bounded by %% signs.
I strongly disagree. The title formatting syntax is quite cumbersome and noisy for non-trivial code. Not to mention the idiosyncratic semantics. Can you give a (precise) description of how Boolean values are handled in title formatting? I think it would be better to take an established scripting language and integrate it into foobar2000 than try to hack new features into title formatting. This is a comparably easy task. The real challenge is to provide suitable ways for this scripting language to interact with foobar2000 which requires a specification of the desired features.

By the way, here is a presentation I found quite interesting regarding the whole issue of notation and presentation of program code. The presented programming language is quite irrelevant to scripting in foobar2000, but I still like the conclusion a lot:
Quote
Notation matters. ... The right notation is half of the solution.


Quote from: odyssey on
Actually I thought of the nice gui of foo_scheduler in the case above. It's not that I'm a big fan of GUI's, but it seem to be the approach that foobar authors prefer in 3rd part components.
Actually, the thing we prefer - not just in third-party components - is that functionality can be discovered and used by untrained users. As it happens to be, textual configuration is very low-level and it is easy to make mistakes. If the user interface prevents mistakes, then that is a good thing in my book.

Scripting Language for FB2K

Reply #5 –
Quote from: foosion on
I strongly disagree. The title formatting syntax is quite cumbersome and noisy for non-trivial code. Not to mention the idiosyncratic semantics. Can you give a (precise) description of how Boolean values are handled in title formatting?


Poorly?

Heh, I see your point. Mine is just that the (relatively few) things that titleformatting's good at, I wouldn't want to see lost.

Quote
I think it would be better to take an established scripting language and integrate it into foobar2000 than try to hack new features into title formatting. This is a comparably easy task. The real challenge is to provide suitable ways for this scripting language to interact with foobar2000 which requires a specification of the desired features.


This is exactly the kind of thing I was looking for an answer to. Thank you. For me, at least (and I'm sure others have other lists), there would be basically two sets of desired features.

The first would be precise control over the display of both player status and track information, such as what is (mostly) offered by things like the Panel Stack Splitter, the WSH panel, and the various track info panels and customizeable playlist renderers. (And, in an extreme case, what Panels UI used to do.)

This is about 90% doable with existing, supported, components, but I don't think anyone would agree that the way it's done is ideal; each component has its own idiosyncratic syntax, each component has its own limitations as to what it can do, about half these components aren't being developed any more, and the way they interact with each other can be, um, interesting at times. Not to mention the nightmarishly complex coding required to use almost any of these things. (Now, I happen to enjoy the challenge of nightmarishly complex coding, but it is a safe bet that I am not the usual case.  )

And there are things that can't, to my knowledge, be done at present that would be very desirable, such as getting the playback order of the player, the name of the current playlist, etc., anything to do with the system date (yes, yes, I know)., etc.

The second would be a way to create chains of actions, as foo_scheduler offers to some degree, but with a greater array of available actions, and an ability to modify those actions conditionally. Essentially setting up macros for FB2K.

Now, again, I'm just asking what's possible, here, and what would be required to make these things happen. The question of whether these things *should* happen is a question that should be asked, but I'm as interested in the hows as in the whys at this point, and the discussion of topics like this seems to very frequently turn into "why" around these parts, with "how" getting ignored as a consequence.

Quote
Actually, the thing we prefer - not just in third-party components - is that functionality can be discovered and used by untrained users. As it happens to be, textual configuration is very low-level and it is easy to make mistakes. If the user interface prevents mistakes, then that is a good thing in my book.


The only problem I see with this ideal, which is one that I otherwise share, is when the ability to do certain things is removed (or never implemented in the first place) because there's no way to make it easy or intuitive. Or when the easy, intuitive things don't behave the way you expect them to, because everyone has different ideas of what easy and intuitive actually mean.

That said, I think the best solution would be a system where, for example, layouts could be created and edited graphically, with the ability to fine-tune things at a low level if necessary (and, ideally, it wouldn't usually be necessary). Certain components already offer this ability to a limited degree.

Scripting Language for FB2K

Reply #6 –
I think that a unified, good scripting language for the UI and maybe other tasks which is properly implemented and solid is what the foobar community desperatedly needs. The official implementation of foobar is fine for the people the devs target, but there are many people on this forum that want more and must resort to using the half-solutions such as Panels UI or WSH panel.

In my opinion such a goal is feasible, it just requires a dedicated developer who doesn't disappear suddenly. And I think an existing language such as Lua should be used.