Magic Nodes 1.3b (IS OUTDATED SEE NOTE IN FIRST POST)

[sadao]

Just in case it wasn't clear, I re-installed MediaMonkey to get the error message to go away (no biggie, just clarifying in case someone else runs into the issue)

Ohh, ok. That's strange . The script will definitely not work if you have two versions in the auto folder, but moving one of them out should solve the problem.

Maybe someone else should try to replicate this issue. Add the new file to the auto-script folder with the old one in there, open media monkey, see error, delete file, open media monkey again and see if the error is still there (as it was for me).

[Pablo]

Maybe someone else should try to replicate this issue. Add the new file to the auto-script folder with the old one in there, open media monkey, see error, delete file, open media monkey again and see if the error is still there (as it was for me).

That happens to me all the time when I'm programming/testing, and in all cases removing the duplicate solves the problem.

[Pablo]

I've just posted a new version of the script. Look in the first message of the thread for details . As always, feedback is appreciated.

[sadao]

Excellent job Pablo. You've achieved full album artist functionality!

And good work on the website. It's nice to see you took the time to build up comprehensive and user friendly documentation.

I'm sure you are making lots of people really happy.

One quick comment about the documentation:

In the tutorial, when you're explaining the album artist node, you write:

Unlike the previous nodes, this one will show up right after the album node from MediaMonkey. This is the result of including child of:artist in the mask.

I imagine you mean to say:

Unlike the previous nodes, this one will show up right after the artist node from MediaMonkey. This is the result of including child of:artist in the mask.

Again, thanks! You've saved me countless hours of programming.

S.

[Pablo]

Sadao, thanks for your words and for pointing out the typo in the website .

In case anyone's interested, here's an Album Artist node that filters the tracks added to the library in the last n days (in the example n is 14 but can be modified)

Code: Select all

Album Artist (new)|child of:artist|SQL filter:DateDiff('d',Songs.DateAdded,Now)<14|icon:top level\<album artist>\<album>

[tralla]

Hi there,

just tried the script for the first time, and yes, it's great!

However, I'm having the same problem with the edit box as jmaver, OK an CANCEL buttons conceal the actual entry form. Seems that I'm running the same skin configuration: "Windows overrides MM". With the standard MM skins, the buttons are as they should be. But I'd love to keep my low-key windows theme...

Anyway, great stuff!

[Pablo]

Tralla, thanks for the feedback!
In the last version of the script (1.2) the windows are resizable, so you only need to enlarge them a little bit to get the buttons out of the way. I'll try to get a better solution for the next release.

[sadao]

Another request for you Pablo:

I would like something along the lines of substr(). Or rtrim() and strlen(). The reason I need this is that I classify my music by super-genres. E.g. ELE - Ambient for ambient electronic music, ELE - Drum & Bass for drum and bass, ELE - Trance for Trance, and so on and so forth.

The Node structure I'm looking to get is:

-Super Genre
- - ELE
- - -Drum & Bass
- - -Trance
- - -Ambient
- - RCK
- - -General
- - -Hard Rock
- - -Heavy Metal

and these would be created from genre tags containing ("ELE - Trance", "RCK - Heavy Metal", etc.)

You can see why I need the rtrim() and strlen() functions; it's easy to create the first level of subnodes by using trim:3, but there is no way to get the sub sub nodes (i.e. drop the first 5 characters from the genre string) . I could make do with the full subgenre name as the sub sub node, but it would be sooooo much nicer if I could just have it as displayed. Pretty please? Obviously this feature would probably be used by all of 1 person, but...

Oh, and while I'm at it, here is another idea:

I have a lot of artist fields filed out like so: artist A / artist B / artist C. It would be great if there was a way to explode the artist into it's three component artists and have them all appear in an artist node, without the multiple artist artist appearing. I think this would be a lot more of a challenge (esp since then clicking on Artist C would have to find the artist A / Artist B / Artist C file), but it would do a great job in cleaning up messy artist nodes...

Keep the good work up. And feel free to ignore my requests, I'll just take as much as I can get .

[Pablo]

Sadao, a qualifier that keeps all but the first n characters of a field should be quite easy to add. It looks like that would do the trick for your first request, assuming that ALL your genres have the form <main genre> - <subgenre>, where <main genre> is a 3 letter word.

The second request is pretty much impossible to implement in Magic Nodes without a complete redesign . One could try to build a completely new script that does that (and only that) but even that looks like a non-trivial problem (at least to do it efficiently).

[sadao]

Sadao, a qualifier that keeps all but the first n characters of a field should be quite easy to add. It looks like that would do the trick for your first request, assuming that ALL your genres have the form <main genre> - <subgenre>, where <main genre> is a 3 letter word.

Well, I would love to see that. Generally, it would be useful for anyone who wants to cram multiple categories within one tag. All my genres will be in the ??? - subgenre form.

The second request is pretty much impossible to implement in Magic Nodes without a complete redesign . One could try to build a completely new script that does that (and only that) but even that looks like a non-trivial problem (at least to do it efficiently).

Yeah, that's what I figured. I was thinking about it a bit and it looks like it would be quite a b?&ch to get it to work. Not only do you have to parse the artist names, but then you have to maintain the relationships with the original unparsed files. I think doing this would require a new access table that relates to the songs table via the artist. I don't even know if the scripting language allows creating new tables. Not to mention that the whole node will probably end up becoming kinda slow. Oh well .

[Pablo]

Well, scripts can create tables by executing SQL code, but I Idon't think it would be necessary here, and in general I think scripts should not modify the structure of the database.

There are certainly ways to achieve that funcionality, they just seem slow since they involve parsing the artists one by one.

[Risser]

I'm trying to see what files DON'T have a quality setting.
I tried:
Quality\<quality|unknown:yes|all:yes>\<artist>

but that doesn't show the unknowns, unless I'm looking in the wrong place.

Am I missing something?

Thanks for all your hard work!
Peter

[sadao]

Well, scripts can create tables by executing SQL code, but I Idon't think it would be necessary here, and in general I think scripts should not modify the structure of the database.

There are certainly ways to achieve that funcionality, they just seem slow since they involve parsing the artists one by one.

I think that the only way to handle this so that it will work quickly enough is by having a sister table to the songs table (i'm saying this cuz i'm dealing with about 30K tracks).

For example, suppose there is a record in the songs table that goes like so:


id: 68
artist: A / B / C

The sister table would have matching records like so:

id: 1
song_id: 68
artist: A

id: 2
song_id: 68
artist: B

id: 3
song_id: 68
artist: C

Then, the node can just read the sister table and still have all the associations to the track info available.

Obviously the big issue is how this sister table gets maintained. Ideally, any time the artist field for any track in the songs table is changed (update or insert) then the sister table should get updated too. I imagine this should not add too much overhead to the operations. Whether this can be done through scripting or not is a whole other issue...

Well, i'm just blabbing. Maybe a plain parsing of the artist would be fast enough. I haven't even looked into the object model to see how the associations of nodes to tracks work so don't take my comments too seriously. Might look at the details of your script over the weekend so I can get a little more insight into the inner workings of the scripting model...

[Pablo]

I'm trying to see what files DON'T have a quality setting.
I tried:
Quality\<quality|unknown:yes|all:yes>\<artist>

but that doesn't show the unknowns, unless I'm looking in the wrong place.

Am I missing something?

Thanks for all your hard work!
Peter

Hi Peter, currently the unknown field is not displayed for many fields, including Quality. Because of the way data is stored in the database it's a bit harder to implement for these fields, but solving this problem is high on the to-do list.

Just in case you're not aware, you can see tracks without a quality setting in the standard Files to edit|Unclassified tracks|Unknown quality node - but you won't be able to organize them by artist there.

[Pablo]

I think that the only way to handle this so that it will work quickly enough is by having a sister table to the songs table (i'm saying this cuz i'm dealing with about 30K tracks).

I'm of the philosophy that having duplicate information is a receipt for disaster , so I would try to avoid sister tables at all costs. In any case, your idea cannot currently be implemented through scripting (tracks can be added to the Library and updated independently of the scripting system).

If you want to learn about the scripting model (especially as it relates to creation of nodes), I would suggest you to look at the sample lyricist node script and other scripts created by jmaver and octopod first. Magic nodes is already over 1200 lines and may not be the easiest one to read .