umm....... *baff*

i tried both as well and both appeared purple *confused*

*searches for whats the cause of this*

- Lyx

edit: could it be that there are problems with reseting the color via

in a column after a transition happened?

I do have it set to that.

What did you mean? I don't have any problems with middle clicks.


Yes it would be something like that. The main point I would have said upNorth has done below.

Other points are:
- The global (non-track) string does not have to use tagz, it wouldn't make much of a difference either way.
- Personally I would not just give plugins access to the string(s) but process it for them. (minor point)
- I am not sure where you are going with the config page cloning. You wouldn't need to clone config pages to make them be imported/exported.

The importer & exporter would also need to be made to ask what you want to import and export

..sounds like fun, and a lot of work. I am not going to do anything that complicated, if someone else does I would gladly use their implementation in columns ui.

If the global support is developed more as discussed below I may move it to a separate plugin with an api but that is it, it is far too much work otherwise..



I think you shuold look again at preferences, those strings are not under the standard ui.

Yes all components can access those strings, and modify them, and get callbacks when they are modified etc...

I was refering to the fact that I format the playlist/window title/status bar/systray strings on my side, whilst the copy string is formatted on the core's side, and so i can't make/force global variables to be available there.



Yes I was trying that on your dynamic string, putting it in a big $if and seeing what impact it had on speed. The portion that fitted in the edit box on the columns ui config page went from 2 ms to 0.5 ms. So parsing the string is kind of slow.



Yes I thought of the same after thinking about what you said actually.

I was going to say that that choosing the colour scheme should really be taken out of tagz, as well as enabling tag guessing like you say.

Choosing a different colour scheme will insert the relevent code into the global string, same for tag guessing, resulting in a slightly more dynamic string as you say. Either that or they are formatted separately, I am not sure what is a better idea.

It would not be through some $functions though, i can't add custom functions like that for one.

Anyway, I am just not sure exactly how the user should be able to add these options/sections into the config page. I think it would end up being a list (maybe a dropdown) with the sections, another dropdown list with the options/categories for that section (e.g. the colour themes, or maybe different levels of tag guessing), a checkbox to enable/disable the section, and the string for the chosen categoriess for that section. And some new/remove buttons for the sections and options.

i think that is the most sensible way with some flexibility.



Dont worry, it is a good idea, kind of far fetched but still a good idea. No, my nightmares aren't that bad.



The problem is that the time would change every second or minute, and the cache would need to be flushed, and whather strings would then be reformatted, and the playlist repainted.

Date is ok, I just am not sure how to get a notification of when the day changes (for it to correctly update if your computer is on for long time).

What format should it be in? Or separate day/month/year fields?


It is simpler for me to process that way, and the global variables is an optional feature.


I think it may invert the desired colour possibly. I will fix it for 0.1.1...

@musicmusic: I really appreciate your answer. As long as you got my drift, it's fine whatever you do as long as it improves on the ways things are currently done.

Regarding the time/date question: I really ment date alone, as what happens from minute to minute, hour to hour, really isn't that important. Choose any format you like for the date. Maybe copying the format tboehrer uses by default in foo_playcount is a good idea? I don't remember what is used there, as I have removed that feature at the moment, because I had no use for it (you might change that).
For me personally it wouldn't matter if the date isn't dead accurate as I turn off my computer every night. What I'm looking for is an easy way to "trace" (not chronological) my listening in the playlist, that day.

[useless]
If you decide to add time too, a possible use would be the option to make the trail in the playlist, fade out as time goes by. How cool wouldn't that be
[/useless]
Edit: If I'm not mistaken, that idea isn't just useless but even impossible...

I agree that common import and export functionality is easier to do than unified configuration, though that would be extremely nice. In fact, about a year ago, I was considering a design similar to what Lyx proposed. My goal back then was to have some kind of preset mechanism for foo_dbsearch that could also be used easily by other components. In the end, I did not implement it, because the design seemd to be too complex.

I'll see, if I can come up with a simple design for a common theme import/export architecture in the next days (or weeks? I'm currently low on free time). If someone beats me to it, well, that's fine with me. If support for such a mechanism can be added with reasonable effort, I'll use it in foo_history and foo_dbsearch. The discussion about this should probably be continued in a new thread...

This condition checking must be handled outside of the Tagz script, and it must be in a token format not used by Tagz.

Something more like %_ext_1%, or even %_whatever_you_named_the_ext%, conditionally inserted. The only problem is, then these extras will have to be declared as empty strings or whitespace when you have them disabled, or else they will need brackets to close them out when they're empty.

This is starting to sound more and more like global strings for the globals. How many levels of nesting do we need? No, wait, don't answer that.

It is quite impossible for a component to add functionality to Tagz directly. If the functionality is to resemble the Tagz syntax, then the caller must parse the entire script and interpret its own tokens before passing the result off to Tagz itself. The more the extra functionality is allowed to depend on regular tokens and functions, the more the host component has to duplicate Tagz.

Thus, simple solutions that work outside of the interpreter without a whole lot of parsing.

I've had similar problems using hex values for colors so I've switched to using rgb values.

Hmm, i agree that upnorth's "extensions"-idea is great and fitting. But if i understood upnorth's proposal correctly, then you would basically switch on/off certain tagz-blocks or var-definitions.

Imho, tagz or another language is very interesting in a global (non-track-specific) "string" (however that "string" looks like in the UI). Some stuff which currently isn't feasible in a track-specific global-string, would be reasonable in a global non-track string. Like i.e. calculations for a selected color-theme.

My current work-in-progress ui_columns string automatically calculates the "selected"-color of each color - and the secondary colors used in transitions. In the current track-specific global string this is barely feasible - but in a global string which only gets executed one single time, its peanuts.

So, imho a language - be it tagz or something else - is very interesting in a non-track-specific global string - especially since it can contain resource-hungry code which only gets executed one single time, instead of over and over for each track.

- Lyx

I would still like to make it work properly though. I suppose I could do it in a retarded manner using a timer unless I find anything better.. Anyway I will probably implement this as an option in 0.1.1, I hope to get a beta out in a few days..


Ok interesting. I will wait and see what you come up with then.


In case you misunderstood me, I meant it could use a language other than tagz. Either that or it could somehow be built in to upnorth's extensions idea, since the only reason for a scripting language in this string is for colour themes I think, unless you can think of any others.

upnorth's proposal is about reducing the length of the global string and taking some decisions away from it, for speed reasons really.

There's some sort of time "standard" that's attempting to be implemented I think... the search functions broken, so I can't find the thread - but here's the format anyway:

%Y-%M-%DT$H:$M:$S$T

Key: http://www.paranoiazplace.co.uk/foobar/tim...pformatting.jpg

Hope that makes sense... I've confused myself somewhat...

Steve

[EDIT] Found the thread: http://www.hydrogenaudio.org/forums/index....ndpost&p=203753 [/EDIT]

Anyone know what happened to the columns upload thread? I PMed a mod but haven't heard anything back yet.

Time info won't be made available, and so I was just going to make them available as separate fields (i.e. %_system_year%, %_system_month%, %_system_day% and %_system_day_of_week%), so yuo can do what you want with them. Unless you can think of a reason not to take that approach?


I dont know what happened to it, but I suggest you use the website instead.

I dont know who is admin there anymore, I think Neksus, spase and dano are, they can make yuo an account (I am kind of busy), there seems to be anonymouse uploads now, wait you seem to have found the site

Please use it instead of these forums, the thread was only ever meant to be temporary whilst the site was made..

Yeh, that sounds good - am I right in saying time won't b available because of the aforementioned update problem? That's a shame... although on saying that - time isn't required for what me and UpNorth have in mind

I eagearly await the next release - will custom hover buttons be implemented or is that still something on the future list?

Steve

Spase made me an account a while ago. I can log in fine, but I get an error when I try to upload my config. When I tried a second time, not only did I get an error, but it claimed the files (screenshot and the zip containing the configs) were already there, but when I pasted the urls into my browser I get a 404 page.

I'm gonna try again right now and I'll copy the error messages here for reference so perhaps someone can help me out.


[edit] error I get when I try to upload my screenshot:



But then it gives me this url:

http://home.outerspase.net/columns/uploads/iMag2012.png

as being where the file is, but that gives a 404.

[edit again] same problem with the config, but replace iMag2012.png with iMag2012.zip.

The error I got the first time around was this:

hmm, would it cost alot of resources or be difficult to make global variables also available to playlist-filters in the column-settings(and use tagz there)?

Just asking because this would be interesting for album-mode display - the user then could set if he wants to give priority to album-mode or single-mode:



In the above example, the column would always be shown if the user did set %_albummode_priority% to 1 in the global-string - otherwise, the column would only be shown if the playlist contains "album" or "-a-".

thanks again for a great alternative UI :-) And on a sidenote, i love upnorths idea of extensions - one thought: it may be interesting if such an extension could not just be switched on and off - but also like a radio-knob be switched between two modes - like, if he chooses "A" then string A gets pasted to the global-string, if he chooses "B" then string B gets pasted. Like an if-choice "either this or that".
- Lyx

edit: could it be that there is a max-limit for the size of the global string?

@Sandman2012

Sounds like there is a coding problem (some code not updated) when the site was moved try sending a PM to spase!

--
Neksus

A question about speed:

I'm currently trying to optimize the speed of my string a bit, since on a 400mhz P2 it lags slightly when scrolling non cached tracks.

So i used the speedtest-button on all of my strings (global and columns). The result was that it would take 20-25ms on average per track. However, that would still mean 40 tracks per second - a value which seems unrealistic compared with my observations. I tried the 2extreme style(a very minimal style) to be sure that its my style which causes the slowdown, and with that style there is no delay when scrolling uncached tracks.

This leads me to the question: what does the speedcheck-button measure exactly? I guess only parsing- & execution-speed, right? Would it then be correct to asume that the slowdown doesn't happen while parsing/executing, but instead during the display?

If yes, then are there some guidelines which stuff slowdowns the display?

- Lyx

I just think having a playlist that needs to be updated every second or minute is a bit ridiculous.

I don't mind making the hour available if you want, I've done day/week/year/dayofweek and it is working fine (updating too).

Hover (mouse over) buttons is implemented yes, 0.1.1 beta is pretty much ready, here is the changelog if you are interested

but I will release probably tomorrow or day after so I can test it a bit more.


Oh ok.

Hrm that looks a bit messed up :/


Not from the current global string, (as it is track specific).

I have no idea how all of these ideas will fit together..

If I make tagz available there it will be optional anyway, since tagz would be slower.

You're welcome


I addressed that in my reply to upnorth (drop down list, each with a different string). Main usage would be colour schemes.


Yes

It is the default limit of the edit control I think - probably 64KB or something. I will change that for 0.1.1. I am kind of reluctant though, if you've got a string that long you should think about deleteing three quarters of it..



25 ms?

That is very slow...

From what of upnorth's dynamic string I could get into the global edit box (and fixed for syntax), I got 2 ms. (I have a athlon 2500+ barton).

Oh 25 ms per track. So that is global + columns + colour(s)?

If you want to know about processing, global (new) is formatted once per track, each column display string is formatted once per track, and each individual colour string is formatted once per track. So if you use the global colour string for all of your columns, the colour string will only be formatted once. (If this changes your 25ms figure).

In regard to comparison to actual performance, global variables are not made available in the display/colour strings. I imagine having them available would make the script slower.

It does not test parsing the colour string or global string, and avoids testing memory allocation (on my side) etc. also. Neither is it tested in circumstances similar to actual circumstances.

So it is just a simple test of the raw script performance, rather than actual performance, and not a particulary fair one at that. I am not sure neither whether the first/seconds/third figure is more closer to actual performance - but it is probably closer to the first or somewhere in between. I will see if I can find out.

I will also see about changing it so the global variables are made available for 0.1.1 for the display & colour strings.

As for display being slow, no since you yourself said that it is ok for cached strings.

As for keeping things fast, I don't really have any specific advise for you, just some general advice - just make your scripts do what they are supposed to do and nothing more, and try to use the tagz functions instead of your own implementations (e.g. $codec(), $progress(), $blend() etc.).

Maybe you want to check what kind of effect removing your $replace colour code mapping has also.

It may be slightly faster with 0.1.1 since I made a couple of changes that may make things faster, also the support for colour code mapping on my side, but probably not anything noticable..

Can't wait for those directory named playlists! Keep up the good work :-D

I PM'ed spase so hopefully I'll hear from him within the next day or so.

Well i just deleted lots of unnecessary detailed comment-lines - especially really long seperators in commentlines (like "// =====================...") and now i've got lots of new space. Because of the color-themes, lots of space gets used by simply doing lots of $puts(color,color-code). Also, lots of space gets used because i'm currently doing the color-code workaround which you proposed to me. Counting all those workaround-puts together (global and all columns) they would for sure fite 4 pages of code.

Also, about 30% of the space is used by tag-guessing - however, this large block gets skipped if files are already tagged.




I am testing this on a 400MHz Pentium2. So, my stated 25ms would probably be much less on your 2500+ Barton :-)

400mhz x 6 = 2400mhz
25ms / 6 = 4ms

And thats not counting architecture differences like ram-speed, cpu-features, etc.



Yes, everything counted together, not just the global-string. However, today i found a nice location in the code where i could save a good amount of cpu-time, so this is now down to 23ms average.

Currently, the global string uses up between 14ms (best case) and 20ms (worst case)

However, if i put all the non-trackspecific stuff into an if-loop, then it goes down to 6-12ms. However, from your earlier experiments with the speed-test button, it seems that even in such a case parsing still uses up about 25% of cpu-time. So, without the non-trackspecific code, my global string would take roughly 4-10ms.

Thats one of the reasons why i am hoping that at some day i can put this stuff into a non-trackspecific global string.

The columns + colors currently use up aprox. 6ms. However, there are currently lots of replace-operations to convert the $char(6)'s back to $char(3) in the columns. Since you said columns could possibly parse $char(6) as well in color-strings, this would probably save about 1-2ms - maybe more, not sure.

What i'm trying to explain: i'm currently building my design with the thought in mind, that via a global non-track-specific strings and dropping the color-code-workarounds, i would later be able to get the processing-delay down to about 12ms.

Which on your 2500MHz machine would equal to less than 2ms for globals+columns+colors.

It IS lots of code - but alot of it wouldn't need to be calculated for each track - and many parts of the code only are needed in certain cases.




many thanks :-)
- Lyx

edit:

So, i'm basically programming a playlist-design on a commodore 64? Cool! Ah, the memories - how to squeeze the most out of 64kb RAM :-)

Hi, quick question.

I just installed fb2k w/ columns on a new computer and all is well, except I am seeing green and red boxes (instead of green check marks and red X's) in the ReplayGain column. What did I forget to install/enable/configure?

Depends on which formatting strings you are using but almost certainly you need to install a unicode font. Neksus recommends Arial Unicode MS for his Azrael formatting strings which you can grab here.

Thanks!

I think I found a minor bug or at least strange behavior (not sure if it has been reported already, see my last comment):

If the text color is changed within the colomn code (custom colour spec for that column is not enabled) the selected text won't revert to the global color after .

The exact column code:

The word 'Tag' should be light blue both for normal and selected text (as defined in "Colour (Global)"). The problem is that when selected the color is inverted (brownish in this case).

IIRC someone reported a green/purple problem not so many days ago. Is this the same thing?

http://209.152.181.168/~hydrogen/index.php...ndpost&p=214689

Yes, it is probably the same thing - musicmusic also said that it seems that the color gets "inverted".

Having the hour available would be great

I look forward to the new release (got my hover buttons ready ).

Cheers, musicmusic

Steve

In 0.1.1 beta, the global variables are made available if they are enabled in the speedtest.

It has some strange results, which can be explained, but Im not going to bother..

As for which result is best, it turns out they are all kind of relevant..

The text limit should also be gone, I didnt test though.


Yes, it is inverted. Try 0.1.1 beta.


Ok, i made them available as special fields in the global variables, since I figured you'd want to set a field like %_played_today% or something.

0.1.1 beta

Changelog above.

Also regarding the crash on import that was reported a while back, I reproduced it but it still is a bit wierd and I only reproduced it once. The only plausible reason I can see is if reader::read() would return something greater than the length you pass it (-1 ?), even though it is supposed to return 0 on error.. Well whatever, it should be fixed now anyway..

0.1.1 beta still doesn't revert back to global. It just ignores  for the selected text and uses the color specifed before 
For short the 'Tag' text in the code I posted is now red instead of inverted (purple).

I'm playing around with the beta now, currently trying to figure out why everything below the text in my sidebar is white.

Btw: I love the sidebar toggle. Thanks!

Thanks, redownload and try again, should both be fixed..

Your welcome

They are.

Edit: There is a minor mistake in "string help" as it says "4 colour codes in..." when it should have been "5 colour codes in..."

hmm, seems like global-vars containing color-codes dont work in transitions, intentional?

color-mapping is enabled of course.

- Lyx

Getting weird behaviour - when I check/uncheck/select anything in collumns prefs, it turns all columns which don't have their own colour codes to black, when their highlighted. As soon as I click to another item in the playlist, everything returns to normal... Until I do something in the preferences again - very weird

Steve

Ok thanks.


There isn't anything I can do about that, I map them back after formatting so $transition recieves the wrong codes..

In that occassion, you will need to map them yourself (replace $char(6) with $char(3)) within the function.


You need to set the fifth colour in the colour string - it was supposed to be optional, but apparently I didnt implement it right.. I will change that for next build.

Am I the only one who hates this?
http://209.152.181.168/~hydrogen/index.php...ST&f=42&t=22117

It'd be great if the current playlist would stay selected even if foobar (or actually even the sidebar) isn't selected.

Otherwise it's a great version again

I have enabled the new date info in the globals tab, but I can't figure out what the right tags are. I thought these where the right ones:

but I guess they're not. So, what to use?

I'm confused by the date info - how do I call it up?

[EDIT] Sorry, I was sittin in a stale thread for 10 minutes - teach me not to refresh [/EDIT]

Steve

erm that link was pointing to 0.1 RC4 somehow :s

Don't worry I added an underscore to foo_ui_columns_.dll and got 0.1.1. But thought other peeps might like to know...

I was going to say check that you have set the non-focus sidebar colour, but the colour selector is broken for that colour. I will fix it soon, and add exporting for thos colours which I forgot.


They should work in the global string (forward them to your other strings if you want)


Sorry the link is correct. Clear your browser cache? And that _ version is older.

Sorry, it was several other mistakes in my code, that caused the problem. Thanks for clarifying though, and for adding this feature.

Ok, I'm confused:

my global variables:

$puts(today,31)

my global colour:

000000|000000|
$if(%_isplaying%,$rgb(220,220,220)|$rgb(204,208,212),
$ifgreater($right($left(%play_stamp%,10),2),$sub($get(today),1),$rgb(225,225,0)|$rgb(220,220,220),
$if($greater($mod(%_playlist_number%,2),0),$rgb(237,243,254)
|$rgb(83,147,227),$rgb(255,255,255)|$rgb(83,147,227))))

Okay, now, that refuses to work, unless I check "use old style global string". The above also works if I substitute the calling of the variable with 31, just to be clear.

I can't seem to get dates to work at all :S

And I sorted out the phantom blackness... mentioned above, its not wrongly coded by you, I just had some random code in my string kept there because I didn't want to forget it, but I hadn't commented it. Previously it wasn't interfering, but with the new colour formats....

Cheers,
Steve

Help... please....

Steve

Wierd. My apologies, I had to resort to IE

Heh - I had the same trouble with Mozilla the other week - I used Getright to download it in the end

Steve

@Paranoia:
Have you checked "Make date info available" in the globals tab?

Also try defining a global and not a variable.

Define:
today=31

Use:
%_today%

You can have a look at mine and see if that helps:
In Globals:


In the column:


%PLAY_DATE% is ddmmyy set by foo_playcount

Edit: Updated the code for Globals (added the first $num() )

Actually, the AMD XP2500 runs at 1.833GHz...

So, then he did actually count some architecture differences after all

Cheers UpNorth - great help

I did have it checked - I just didn't know about these global things

Thanks again

Steve

Old style global string unsuportted feature, it doesnt have teh dates.



I didnt think there was anything wrong

Yes I did actually change the way they are processed (faster) but requires proper output of the string..

Updated 0.1.1 beta uploaded, fixed selecting of non-focus sel sidebar colour and added exporting of those new colours.

I'm happy to see you added on mouse over button graphics to the UI. One problem, though: the 0.1.1 beta has weird problems showing certain colors in bmps that it didn't have back in 0.1. Maybe this is because for some reason you are limiting the color scale in 0.1.1?
Here is a bmp of only the hover part so you can also works in 0.1:
http://brusi.3kd.net/stuff/columnsuibug.bmp
Try using it for the buttons in 0.1.1 beta and then in 0.1 and tell me if you experience the same problem. (Just to be clear let me say this peoblem doesn't have anything to do with whether you turn on mouse over or not).

Also, would be nice if by 0.1.1 final you would add an option to add/remove buttons because I, for example, don't need the open button or the random button. Another useful thing would be fusing the play and pause buttons into one button.

I see the other more important requests But I'm still expecting