Should be pretty much self-explaining - what ability do you miss most in formatting-strings?

"LUA-Support inside TAGZ":
This would pretty much tear down most limitations of TAGZ, yet still retain the compatibility and ease of TAGZ. It would allow some really powerfull string-programming with few codelines. Just put your LUA-code inside $lua(blah)

"Define real-columns inside strings"
Build real columns by defining something like $column(blah,column-name,initial-width) inside strings which are also sortable.

"General-purpose-string with persistent variables"
This would add another area in the fb2k formatting settings, to paste a string into. The variables set in this string would be persistent, so that other strings from the playlist, statusbar, etc. can $get() them. Would eliminate dupe-code which repeats in different strings, like tag-guessing.

"Access to all playlist-items, instead of just current"
This would allow access to %blah% from any file in the playlist by specifying the playlist number. Usefull for album-mode or other advanced drawing technics.

I voted for "real-columns".
- Lyx

Access to all playlist-items, instead of just current: yes, that would be nice indeed.
Actually, I voted for "Something else": maybe that would be nice to have the possibility to use different fonts in the same playlist tab. Just a thought.

I voted for "Access to all playlist-items, instead of just current" but realized that what I really should've voted for was "Something else". It'd be totally great to be able to change fonts (and all options related to fonts ie bold, italics, etc) directly in TAGZ.

lyx: do you know that there's new, c-like language in development version of foobar? i've seen screenshots, it would basically allow for structured code etc. you won't be able to make 'more', though resulting scripts would be easier to read etc.

i've been discussing lua support (given proper callback in the core, lua or anything could be used to create strings for playlist items ...), although there could be problems with speed / lua's garbage collection. and you could end up with script that wouldn't end (so we would need something like timeout or limit instruction counter etc)

what i would like to have - of course many things you've mentioned would be nice (they could lead to some problems though). me, i would like:

1) some sort of cycles. maybe 'for'. the reason for that is that i want to process some data repetitively, and without cycles, you would end up with huge, not-flexible script. cycles could go for on and on, so that could be dangerous.

2) better variables' handling (this is probably going to change because of the new c-like scripting)

3) for the new scripting, i would need ways to construct variable names (in loops, that is). something like 'varname # index = ...', this would make variable with name 'varname' + value of 'index'. my example syntax is probably bad thing, something like varname[index] could be better (pseudo arrays, internally it would mean variable with name 'varname' + '_' + value of 'index' etc)

4) regular expressions ... find, sub ... these would definitely help ...

-- as for lua, that could be interesting experiment. there could be callback like create_playlist_string(metadb_handle, playlist_index), which would return string to use. that could be optional and just for adventurous ppl. foosion could support this in his foo_lua (although, for security reasons, he would probably have to add that timeout and some sort of caching / keeping scripts in memory, so garbage collection wouldn't kick in all the time - with some trial-and-error it may even do garbage collection only when idle or over some memory limit)

Oh no! Nope, i didn't knew that..... if i would, then i would have waited for a release, before rewriting more than 150 lines of tag-guess spaghetti-code :-/

hehe same here, i was just about to rewrite my own string ... guess i'm gonna wait then

I voted for the Lua option. If that were implemented, all the other things could be easily added on and/or extended.

What you are saying is that tabs and spaces can be added to structure code, but won't be visible in playlist? But apart from that nothing new, or?

If people complain about my dynamic formatting now, I guess something like "Access to all playlist-items, instead of just current" will make it unbearable when it comes to speed.

Limited support for loops would be nice, and functions too. I'm not really an experienced coder, but I would like something like that if it is possible without introducing too many possible problems because of bad coding.

yes, upnorth, you're quite right ...

about the limitations of TAGZ:

i can only speak for myself: I wouldn't need such a powerfull language as Lua. A more well structured language like the one mazy talked about, the ability to define functions, and the ability to search a string for patterns(regular expressions) would do it for me.

Limited loops would be nice, but not necessary for me, if there are functions and regular expressions.

- Lyx

I voted for 'Define "real-columns" in strings', as it would make some of the formatting work easier. Some of the other ideas are also good, especially anza's and mazy's. I'm looking forward to see what this new C like scripting language will be like .

Real columns undoubtedly!

Listview + RTF support. OMG ERECTION!

Al

Real columns and getting info from tracks other then the currently playing track.

seems like the use of a "general-purpose-string" is a bit underestimated. Such a string would not just eliminate dupe-code, but could also used for other stuff - like a centralized configuration-part from which to setup all other strings - things like unified-color-themes would also be easier that way.

It may not be the most important possible feature, but still IMHO a very interesting one. And i suppose also maybe the easiest to implement.

i'm with you on that one lyx ... i requested something like that some time ago ...

it would be really easy to do, just add one new tab called 'common' and concat it with other strings prior to using them.

you could put all configuration / guessing / common code into it ... and leave 'place/use specific' formatting in other pages.

other way to use it (than automatic concation) could be something like:
$get(%__common%)

i misunderstood you first ... this is really a must!

btw, on a side note: i've just finished another easy foo_lua script, which expands selection to whole albums (even supporting multi-cd albums with subfolders) ...

mazy, if such a string would be implemented, style designers could even discuss some kind of color-naming-standard. A set of variables which different styles share - like artist-color, album-color, title-color, frame-color, etc.
Then, users could change between formatting-strings and keep their color-theme.

- Lyx

yes, that could really be the case, although many scripts (or at least mine) need stuff like separator and separator color for 'artist - title' pairs, other for 'various artists - album artist' etc. ... i mean it's very specific

though there could be standard (commonly used) subset ...

well, no one would be forced to support the standard still, many styles do share the same subset of color-strings, but just name them differently. And even if this subset-standard wouldn't support all colors a string uses, it should be easier to adjust some specific colors, than to set ALL colors again and again on every style-change. But maybe i'm too optimistic in this case. However, its just an idea of what would be possible.

- Lyx

edit: one rule of the standard could be, to either support it(this would mean including ALL variables of the subset even those not used in the string, at the beginning of the common-script), or NOT support it(which would mean to NOT use any of the variables of the standard, so users can keep their subset-section)

yeah that's a bit complicated ... we would need either two common strings (one for script writers and one for user-side colors etc)

sorry... wrong topic

hmm, i don't know if there really would need to be 2 subsets. Making the subset to restrictive and specific would kinda beats its purpose, woudln't it? I'd stick to general color definitions and few really general technical switches like "tag-guess on/off", "album-mode on/off", etc. More specific options should be the job of the styles themselves.

Managing such a subset-standard would also be quite easy:

either support it:
- position the subset-config at the TOP of the common-string
- include ALL options defined in the subset, even if your style doesn't support some
- attach a comment to the options, which don't apply to your style

or not support it at all:
- don't use ANY of the variables, defined in the subset-standard

I can't think of any problems, if it would be handled that way.
- Lyx

Real columns for sure.

Ugh, I said 'real'.

i do not expect real columns in the default gui ... and i like it just the way it is

as for that common string ... well lyx, for me, i would love to have all my tag guessing code in it, so i won't have to duplicate it for playlist, systemtray and all the others ...

I voted for real columns ofcourse :)


Tag-guessing is a big problem too. But I wouldn't do it with variables, as it would require to change all formatting strings.

Instead I'd define somewhere in prefs "macro" (formatting string) that is used instead of %artist%. And define %_realartist% with untouched %artist%.

I chose something else because I would like to have access to the mass tagger component from the playlist. This would make it much simpler to guess tag values from the filename and directory structure.

For Example:
$guesstag(%_path%,%artist_name%\[%album_year%] %album_name%\%track_number%. %track_title%)
or
$guesstag(%_filename%,%track_number% - %track_title%)
where
artist_name, album_year, album_name, track_number and track_title would be variables defined in the playlist code.

Real columns and the c-like programing language that mazy referred to would be cool too.

I voted other. I'd like to see total albvum time. I'm not sure how that could be impleented, but it would make the album list feature more useful.

nbv4, that kind of info won't be easy to add ...

my tag guesser script can process playlist to add such a info, see screenshot

what you're looking for is "access to all playlist items instead of just current". You could then just check the album-tag to identify the songs from the same album, and add their total length up.

User definable functions would be awesome, especially if you could use the functions anywhere where formatting strings are used (masstagger, sort by, renamer, etc). Like the ability to have your own $fixThe() or something, that took "The Rolling Stones" and turned it into "Rolling Stones, The". The tag_guessing code could also be made into another function. Would reduce clutter in a lot of scripts, and just be pretty cool in general.

I'm pretty sure mazy already said something along this line when he mentioned a "common" tab.

lyx: that would of course made it possible, however it would slow things down a lot. i'm quite sure that won't get implemented. we may get something like 'next' and 'prev' prefixes for referencing tags from next / previous item in playlist / playback order

greenirft: i agree, that would be nifty feature & save a lot of space ... i'm not sure that it would be safe / fast enough to get implemented (recursive calls or cross-calls could get ignored quite easily; functions would get expanded internally whenever the formatting string changes, so there would be little if any extra work)

how about deleting files physically form disk using right-click menu??? i really need it. (or maybe i've missed something? )


--------------
www.de2k.z.pl

de2k, there's already plugin for that (you should use 'search' more )

look at this post

*** this post is really just props to the code writers. I was just wanna say wow.

Hey there. I've been a long time user of foobar and have been really pleased with its relatively low cpu util and simple interface.

But what I really bitched about was the lack of an incremental search like that of itunes and lack of track control with my logitech keyboard. I've sinced discovered that there is incremental search that works just fine and that, OMG, my multimedia keys on my keyboard are also compatible.

That is badass. foobar is really coming around with its feature set that maybe one day it will go really mainstream as an audio player. Hopefully it does not got he way of winamp and also become a video player, food dicer, and refrigerator. Also, the masstagger that now consults cddb or freedb to guess the tracks is excellent. Really takes the work off of the end user and that's the goal right?

Thanks for just making a great player that just blew my mind (enough to register and account and rant just that)

Voted for "all playlist items". Adding this would expand possibilities in formatting strings considerably.

You can do this with proper Tagz formatting strings.

I want something like the MediaLibrary in Winamp, with which I can browser ShoutCast-Streams!11

smart capitalization would be cool.

Yes, but you have to put the little piece of code in ever single place where you want to use it. Then you would also have to make a slightly modified version if you wanted to do it on something other than ARTIST. So, if you were using it to sort, you have this huge string in the little tiny sort dialog, or in the masstagger.

The idea is that you define commonly used usermade functions that you can use any place where the formatting strings are used. Just makes it easier to read/debug/modify string formatting stuff.

off-topic. This thread is, as the name implies, about formatting strings and formatting strings ONLY. Please read topics and the first post fully, before writing an answer without knowing what the thread is about.

- Lyx

Uninteresting.

Oh, and that access-to-whole-database idea sounds like it would incur a LOT of overhead. Exponential title formatting overhead, anyone?

what does that relate to exactly?