Magic Nodes
Version 4.3.2
- MediaMonkey Add-on -

by Zvezdan Dimitrijević

This add-on works with MediaMonkey v2.x-4.x. It lets you create new tree nodes using masks which are loosely based on the way that Auto-organize works. There are 370 already predefined masks, for example: artist grouped by first letter [A]-[Z], albums sorted by year, playing statistics, album ratings, random tracks, ... Magic Nodes add-on is based on the 1.3b version of the script by Pablo Shmerkin, but it is almost completely rewritten and drastically improved. Here is some excerpt about this script from his site:

"MediaMonkey is the best jukebox/music organizer around. Magic Nodes, a script designed to work with Media Monkey 2.3 and up (some features work only in MediaMonkey 2.4 and up), extends its capabilities even further. In short, Magic Nodes lets you create new tree nodes in an intuitive and highly configurable way. For advanced users, Magic Nodes includes SQL filters, which provides ultimate flexibility for the creation of nodes with Playlist functionality."

For a discussion about this add-on, you could visit its related MediaMonkey forum thread. If you are using some skin which is not supported by default, you could take a look of skin styles for this add-on made by nynaevelan at the next forum thread. If you are the first time user, it is recommend that you read the PDF manual written by Rick Parsons (it is outdated and covers only v1.7.6.2, but explains many things needed for understanding this add-on).

You could also take a look on my other add-ons for MediaMonkey.

Donation

This add-on is donationware. It is developed by me in my own free time. I am not employed by Ventis Media, the company behind MediaMonkey, nor I've been paid by them for this add-on. So, if you found this add-on useful and want to help its further development, it would be nice if you send me some small donation using PayPal and you will get the new enhanced version that is available only to donors. Just leave me a note about your e-mail address, if it is different than the one that you have registered at PayPal, since I am sending the enhanced version of the add-on using e-mail attachment.

If you didn't get my e-mail for a day or two after your donation, you could check your Spam folder first and, if you cannot find it in there, please send me an e-mail with the information about donation to: . Actually, if you are a GMail user, I recommend that you put my e-mail address to your Contact list before you make donation, so that GMail will not treat my e-mail sent to you as a spam. Thanks in advance!

Euro (EUR) US Dollar (USD)

Compatibility

This add-on doesn't work with MediaMonkey v5! Actually, none add-on made for some previous version of program could work with MM5, either by me or by another authors, since MM5 has completely different programming interface than before. If you really like my add-on and think that it is essential for your work with the program, you have several possibilities:
- you could stay with MM4;
- you could ask MM developers to implement support for old add-ons in MM5;
- you could wait for me to port the add-on to MM5, but don't hold your breath.


MagicNodes-4.0

What is new

v4.3.2 - 2016-04-24

v4.3 - 2015-06-22

v4.2 - 2011-07-01

v4.1.5 - 2011-06-22

v4.1.4 - 2011-05-29

v4.1.3 - 2011-05-09

v4.1.2 - 2011-03-07

v4.1.1 - 2011-02-18

v4.1 - 2011-02-07

v4.0.4 - 2010-06-24

v4.0.3 - 2010-05-21

v4.0.2 - 2010-04-21

v4.0.1 - 2010-04-04

v4.0 - 2010-04-01

v3.0.3 - 2009-09-08

v3.0.2 - 2009-09-08

v3.0.1 - 2009-09-07

v3.0 - 2009-09-06

v2.7 - 2009-06-29

v2.6 - 2009-06-16

v2.5 - 2009-05-14

v2.4.1 - 2009-05-11

v2.4 - 2009-02-20

v2.3 - 2009-02-02

v2.2.3 - 2009-01-24

v2.2.2 - 2009-01-23

v2.2.1 - 2009-01-21

v2.2 - 2009-01-20

v2.1 - 2009-01-13

v2.0.8 - 2009-01-11

v2.0.7 - 2009-01-09

v2.0.6 - 2009-01-07

v2.0.5 - 2009-01-07

v2.0.4 - 2009-01-01

v2.0.3 - 2008-12-21

v2.0.2 - 2008-12-16

v2.0.1 - 2008-12-14

v2.0 - 2008-12-13

v1.8 - 2008-11-08

v1.7.8.4 - 2008-10-30

v1.7.8.3 - 2008-10-26

v1.7.8.2 - 2008-10-23

v1.7.8.1 - 2008-10-12

v1.7.8 - 2008-10-08

v1.7.7 - 2008-06-29

v1.7.6.2 - 2008-06-19

v1.7.6.1 - 2008-06-09

v1.7.6 - 2008-05-27

v1.7.5.4 - 2008-05-19

v1.7.5.3 - 2008-05-16

v1.7.5.2 - 2008-05-07

v1.7.5.1 - 2008-04-07

v1.7.5 - 2008-03-23

v1.7.4.2 - 2008-03-05

v1.7.4.1 - 2008-02-09

v1.7.4 - 2008-02-04

v1.7.3 - 2008-02-01

v1.7.2 - 2008-01-28

v1.7.1 - 2008-01-26

v1.7 - 2008-01-23

v1.6.2.4 - 2008-01-15

v1.6.2.3 - 2008-01-14

v1.6.2.2 - 2008-01-12

v1.6.2.1 - 2008-01-11

v1.6.2 - 2008-01-08

v1.6.1 - 2008-01-03

v1.6 - 2007-12-31

v1.5.0.2 - 2007-12-20

v1.5.0.1 - 2007-12-17

v1w5 - 2007-12-17

v1.4.3.1 - 2007-07-27

v1.4.3 - 2007-07-26

v1.4.2 - 2007-07-17

v1.4.1 - 2007-07-14

v1.4.0 - 2007-07-11

v1.3c - 2006-08-18

Installation

Note: The MagicNodes.ini file is used only after the installation. During its work, the Magic Nodes add-on stores masks into the MediaMonkey.ini file.

Information about version 4.1

Split Mode qualifier could accept two new arguments, Odd Parts and Even Parts. They are similar to Categories argument since they have the same execution order of parsing command, i.e. the Split by qualifier is applied first, then the each resulting part of the string is parsed using Left/Right of qualifiers (if they are specified). Main difference is that Categories argument returns all parts from some string, but Odd Parts and Even Parts returns only every other part of string alternatively.

Usage of these qualifiers is most practical with the Involved People field if it is stored in the ID3 format. For example, the earlier illustration with "Vocals: Bono; Guitars: The Edge; Bass: Adam Clayton; Drums: Larry Mullen, Jr." is not compatible with the ID3 standard, and it should be written as "Vocals;Bono;Guitars;The Edge;Bass;Adam Clayton;Drums;Larry Mullen, Jr.", i.e. the same separator ";" is used between roles and persons and between persons themselves. So, if you have such format and want to display all roles, you could write <Involved people|Split by:;|Split Mode:Odd Parts>. Also, if you want to display persons, you could write <Involved people|Split by:;|Split Mode:Even Parts>.

With these two new arguments you have a possibility to specify roles and sub-roles using Exclusive Left of and Exclusive Right of qualifiers as well. Here is the same Involved People example as before, but adjusted for ID3 tag: "Band member-Vocals;Bono;Band member-Guitars;The Edge;Band member-Bass;Adam Clayton;Band member-Drums;Larry Mullen, Jr.;Guest musician-Guitars;B.B. King;Guest musician-Vocals;B.B. King". To get main roles you should write <Involved people|Split by:;|Split Mode:Odd Parts|Exclusive left of:->, to get sub-roles you should write <Involved people|Split by:;|Split Mode:Odd Parts|Exclusive right of:-> and to get persons you should write <Involved people|Split by:;|Split Mode:Even Parts>.

With this version of the add-on there are 4 new <Poly *> fields. They are similar to <Multi *> fields, but their display is more friendly. For example, with Multi Artist = "David Bowie; Queen" we would get displayed Poly Artist = "David Bowie & Queen". If there are 3 or more artists in some multi-item Artist field, only the last one would be separated with "&", other ones would be separated with ", ". Some users prefer to store the type of the featuring artists as new item in multi-item Artist field, for example: Multi Artist = "Freemasons; feat.; Siedah Garrett" - using <Poly Artist> field you would get "Freemasons feat. Siedah Garrett". Here are several more examples:
- "Dave Armstrong; Redroche; feat.; H-Boogie" -> "Dave Armstrong & Redroche feat. H-Boogie",
- "Jerry Ropero; Denis The Menace; pres.; Sabor; feat.; Jaqueline" -> "Jerry Ropero & Denis The Menace pres. Sabor feat. Jaqueline",
- "Robbie Rivera; Axwell; JJ; feat.; Suzan Brittan" -> "Robbie Rivera, Axwell & JJ feat. Suzan Brittan".

Information about version 4.0

Several added things need some more explanations; the first is possibility to generate nested playlists. I think it is pretty straightforward - just enter your mask as usual and specify Child of:Playlists and Position:Child qualifiers or using GUI you should choose Position: Child of - Playlists (first select Playlists from the second dropdown list, then Child of from the first one). Well, it is the same syntax which is already introduced with the version 3.0, but the big difference is that now you could specify sub-nodes, e.g.

Test mask|Child of:Playlists|Position:Child|Filter:<Lyrics> <> ''\<Arstist>\<Album>

With v3.x you could specify the same mask, but it would generate playlists only with the global (Test mask) node; however, with v4.0 you would now get nested both Artist and Album local sub-nodes. Be careful with the number of generated sub-nodes, because too much playlists could slow down the computer. Of course, as with the previous version, the global node could be nested inside of group nodes in the same way as the other Magic nodes outside of the Playlists branch. There are several limitations with such nodes as with the previous version, i.e. you could not use Show tracks, Statistic and Icon qualifiers with them. You could specify Sort by qualifier, but there is a chance that you would not get what you want, because playlists are always sorted alphabetically (in such case consider a possibility to add Show rank qualifier, i.e. turn on the Show ordinal number option).

If you want to move some existing node from Magic Nodes to Playlists branch, but you don't want to get sub-nodes, you have two possibilities: you could remove sub-nodes from the mask or you could turn off the Show nodes option, but that option could be used only for the last (bottomless) level of nodes, so that possibility is only applicable for masks with only one sub-level of nodes.

The introduction of the next possibilities is a reason for masks incompatibility with older versions, i.e. none of your masks with the Split by qualifier will not work as you want. The first important thing you should know is that all non-negative values for Split part are now shifted for +1. For example, instead of Split part:0 you should now specify Split part:1 and so on. Beside of the added functionality, I think this is also more natural/logical, because the specified value now represents the actual part of the field which you would get, instead of the previous version where you was forced to specify Split part:0 for the first part, Split part:1 for the second...

However, beside of the better logical representation, the main reason for such change is the added possibility for use of the reverse parsing, i.e. the parsing from the right to the left, using negative values for the Split part qualifier in a similar way as you could specify negative values for the Substring start and Trim qualifiers. So, if you specify Split part:1 you would get the leftmost part and if you specify Split part:-1 you would get the rightmost part of the field. Of course, if you specify Split part:-2 you would get the second part of the field from the right, and so on.

The another important thing that you should know, is that now you need to specify Split mode:String part if you want the same behavior as with the previous versions, of course with already explained difference for Split part values. For example, if you had Split by:;|Split part:1, you should now write Split by:;|Split part:2|Split mode:String part. Here are some more examples - let say that I have the Path = "c:\My Music\Pink Floyd\Us and Them.mp3" and using the Split by:\\|Split mode:String part:

  • with Split part:1 or Split part:-4 I would get "c:";
  • with Split part:2 or Split part:-3 I would get "My Music";
  • with Split part:3 or Split part:-2 I would get "Pink Floyd";
  • with Split part:4 or Split part:-1 I would get "Us and Them.mp3".

    If the Split mode qualifier has just that single argument (String part), then there wouldn't be any reason for its introduction. So, beside of the String part argument, the Split mode qualifier also accepts String Before, String After, Single Part, Parts Before, Parts After, All Parts and Categories arguments. Here are examples using the same Path value as previous, but now with the Split mode:String Before:

  • with Split part:2 or Split part:-3 I would get "c:";
  • with Split part:3 or Split part:-2 I would get "c:\My Music";
  • with Split part:4 or Split part:-1 I would get "c:\My Music\Pink Floyd";
  • with Split part:5 I would get "c:\My Music\Pink Floyd\Us and Them.mp3".

    As you could see from those examples, when using String Before you would get the left part of the field's string before the specified part. Here are examples with the Split mode:String After which could be used to get the right part of the field's string after the specified part:

  • with Split part:0 or Split part:-5 I would get "c:\My Music\Pink Floyd\Us and Them.mp3";
  • with Split part:1 or Split part:-4 I would get "My Music\Pink Floyd\Us and Them.mp3";
  • with Split part:2 or Split part:-3 I would get "Pink Floyd\Us and Them.mp3";
  • with Split part:4 or Split part:-2 I would get "Us and Them.mp3".

    Negative values for Split part used with String * arguments (String part, String before, String after) of the Split mode qualifier is not possible with MediaMonkey 2.x, but only with v3.x. Be careful, if you use String * arguments, and if you specify the large value for Split part, you could get the error message! This is because the complexity of the generated SQL code raises exponentially with each value increment.

    The next argument of the Split mode qualifier is Single part. It has almost same effect as String part, with some pros and cons. Its advantage is that it does not generate the error message with the large values for Split part, since it is not using the SQL code, but VBScript instead. However, its drawback is that it cannot be used with Sort by/Statistic qualifiers as well as almost none Show * qualifiers. Same advantage and drawback have all remained Split mode arguments.

    The Parts before and Parts after arguments are similar to the String before and String after arguments respectively, but instead of the one resulting node with concatenated multiple parts of the string, they could generate multiple nodes with the single parts of the string each. Let's see again what we got with Split mode:String After|Split part:1 - "My Music\Pink Floyd\Us and Them.mp3". This is just one node. Now, if we replace String after with Parts after, we would get three nodes on the same level: "My Music", "Pink Floyd" and "Us and Them.mp3". Well, this example with the Path field is not the best nor too much useful, since those arguments are better with the multi-item fields or those fields that could contain multi-item values like the Involved people. Let's try again with some another field, e.g. <Multi Genre> = "Dance;House;Club". Using Split mode:String After|Split part:1 we would get one "House;Club" node, but using Split mode:Parts After|Split part:1 we would get two nodes on the same level - "House" and "Club".

    The All parts argument is the special case of the previous argument, i.e. it has the same effect as Split mode:Parts After|Split part:0 where all parts are displayed as nodes on the same level within their parent node. This argument is default for the Split mode qualifier, i.e. if you omit this qualifier it would be same as if you specify Split mode:All parts. If you are using this argument you don't need to specify the Split part qualifier (it would be ignored). Also state for the next, Categories argument.

    Now, you may think that All parts argument has the same effect with multi-item fields as previous versions of add-on using Split part:-1, but this is not exactly the case; it is the Categories which has the same effect. For example, if you had the mask with Split by:;|Split part:-1, you should now write Split by:;|Split mode:Categories. The main difference between those two arguments is in the order how parsing of the initial field's string is done, and such explanation requires some digression about existing qualifiers which could be used for parsing.

    I suppose that you already know that we have several ways to parse the initial field's string. There are Substring start and Trim qualifiers, then there is the Split by qualifier and finally there are (Ex) Left of and (Ex) Right of qualifiers. The older versions of this add-on didn't have a possibility to use those qualifiers with each other, i.e. you could not use Split by together with Trim or Left of. Well, this was improved in time and now you could freely combine all those qualifiers, but I never explained what is happening internally, and I think that you should know that. The parsing of the initial string is executed in 3 steps: in the first step the initial string is parsed using the Left/Right of qualifiers, then the newly string is parsed with the Split by qualifier and finally the resulting string is parsed using Substring start/Trim qualifiers.

    Here are some examples using the same Path value as before. If I write Right of:My Music\\|Split by:\\|Split mode:String part|Split part:2, in the first step the initial string would be trimmed from the left using the Right of qualifier (resulting with "Pink Floyd\Us and Them.mp3"), then in the second step the resulting string would be parsed using Split qualifiers, so finally I would get "Us and Them.mp3". This is the nice trick to know if you need to use Split part qualifier with large values and some of String * arguments, since if you use Right of you could decrease the Split part value and avoid generating of the error message.

    The presented order for parsing of the string is almost always same, the only exception is the Categories argument, and this is the main difference between All parts and Categories arguments. With the All parts argument the initial string is parsed first using Left/Right of qualifiers (if they are specified), then it is parsed using the Split by qualifier, as it is already explained. With the Categories argument instead, the initial string is first parsed using the Split by qualifier, then the each resulting part of the string is parsed using Left/Right of qualifiers (if they are specified).

    Here is same example as with the 3.x version of add-on, but instead of Split part:-1 we now should use Split mode:Categories: Involved people = "Vocals: Bono; Guitars: The Edge; Bass: Adam Clayton; Drums: Larry Mullen, Jr.". If we write Split by:; |Split mode:Categories|Ex Left of:: , the initial string is parsed first using Split by qualifier and we get 4 parts "Vocals: Bono", "Guitars: The Edge", "Bass: Adam Clayton" and "Drums: Larry Mullen, Jr." In the next step the each part is parsed using the Ex Left of qualifier, so we finally get four nodes on the same level: "Vocals", "Guitars", "Bass" and "Drums".

    Here is one example that not worked before as it should: Comment field = "Country: France/USA". If we use Ex Right of:: |Split by:/|Split mode:Categories we are still parsing the string using Split by first and so we would get two parts: "Country: France" and "USA". In the next step, after parsing with Ex Right of we would get only one node "France", because "USA" part doesn't contain ": " separator. Well, such field layout could be modified for use with the previous qualifiers, i.e. the Comment field could be modified to "Country: France/Country: USA", but it would be really annoying to modify tags in all tracks. Luckily, there is now this new argument, All parts, which should be used with the presented field layout as: Ex Right of:: |Split by:/|Split mode:All parts. With this argument we first get trimmed the initial string from the left using Ex Right of, so we get "France/USA"; then we parse resulting string using Split by, so finally we get two nodes, "France" and "USA".

    There are 4 basic modes for parsing the string using the Categories argument, depending of used (Ex) Left/Right of qualifiers:
    1. using the Exclusive left of qualifier to get the leftmost part;
    2. using the Exclusive right of qualifier to get the rightmost part;
    3. using the Exclusive right of and Exclusive right until qualifiers to get the middle part;
    4. using the Exclusive right of and Right until qualifiers to get splitted right part(s).
    The first 3 modes are pretty self-explanatory and already known from the previous version of the add-on. Here is again the same example as before: "Band member-Vocals: Bono; Band member-Guitars: The Edge; Band member-Bass: Adam Clayton; Band member-Drums: Larry Mullen, Jr.; Guest musician-Guitars: B.B. King; Guest musician-Vocals: B.B. King". Here we have involvement groups on the leftmost side: "Band member" and "Guest musician", then we have roles in the middle: "Vocals", "Guitars", "Bass" and "Drums", and finally we have musicians on the rightmost side: "Bono", "The Edge", "Adam Clayton", "Larry Mullen, Jr." and "B.B. King".

    Those 3 modes are sufficient if we write category for each artist, but it could lead to the duplicated text. For example, if some track have two vocalists, we need to enter e.g. "Vocals: Bono; Vocals: The Edge; Guitar: The Edge". Now, it would be nice if we could write: "Vocals: Bono/The Edge; Guitar: The Edge". This is exactly where could be used the forth mentioned mode of the Categories argument: with the Split by:; |Split mode:Categories|Exclusive left of:: we could get the leftmost part as usual: "Vocals" and "Guitar", and now using Split by:; |Split mode:Categories|Exclusive right of::|Right until:/ we could get "Bono" and "The Edge" (of course, in this example "The Edge" would be under two nodes, Vocals and Guitar).

    Here is the last example which demonstrates usage of Categories argument with the mentioned forth mode. Let say that we have Custom1 field = "Country :France/USA; Tones: Reflective/Ethereal; Style: Prog-Rock/Art Rock". We could create just one mask for all included categories: Example\<Custom 1|Split by:; |Split mode:Categories|Ex Left of:: >\<Custom 1|Split by:; |Split mode:Categories|Ex Right of:: |Right until:/>. With this mask we would get two level of nodes; on the first level we would get "Country", "Tones" and "Style" nodes, where the "Country" node would contain two sub-nodes, "France" and "USA", the "Tones" node would contain "Reflective" and "Ethereal" sub-nodes, and finally the "Style" node would contain "Prog-Rock" and "Art Rock" sub-nodes.

    The 4.0 version has also added First/Other Artist/Album Artist/Genre fields. For example with the First Genre field I could get the leftmost (main) genre from the multi-item genre, and with the Other Genre I could get remaining genres (sub-genres) from the multi-item genre. For example, with "Dance;House;Club" using First Genre I would get "Dance" node, and using Other Genre I would get two nodes on the same level: "House" and "Club". Well, I could get almost same results using <Multi genre|Left of:;> for the first genre, and using <Multi genre|Split by:;|Split mode:Parts After|Split part:1> for the remaining genres, but, as I already mentioned, the nodes with the Split mode:Parts After cannot have Statistic qualifier and have some another drawbacks which the First/Other fields don't have.

    Important

    Split options are changed in v4.0 and your masks containing them will not work as they should. You need to update such masks accordingly to the information about usage of Split options that could be found at the Information section on this page.

    Version 2.0 of this add-on has an advanced graphical user interface which uses dynamically populated dropdown lists. Skinned versions of MediaMonkey from 3.0 till 3.1 have very serious bug with dropdown lists which sometimes results with unresponsive program and 100% CPU usage. All versions prior of 3.1 also have very serious bug when reading keys from .ini files which are longer than 2048 characters (some Magic Nodes masks could be longer) and this bug sometimes results with disappeared program during execution. It is highly recommended to use the latest version of MediaMonkey.

    Since v1.7.6 of this script there is an installation package. If you have already installed some older version (those with version number in the file name), you should manually remove it from the Script/Auto folder before the installation.

    Possible reasons why your old mask (MM2 and/or MN <= v1.3) doesn't work:

    Notice

    This add-on is a false positive reported as a worm by F-Secure. The author of F-Secure promised me that will update its database and put the add-on on white-list, but still didn't. If you go to the www.virustotal.com/en/ site, you will see that it is safe tested by 54 popular anti-virus engines; the only one reporting a worm in it is F-Secure.