Magic Nodes
- MediaMonkey Add-on -
Version 4.0.4

by Zvezdan Dimitrijevic

This add-on is for use with MediaMonkey v2.x or v3.x. It lets you create new tree nodes to help you manage your music library. New nodes could be created using masks which are loosely based on the way MediaMonkey auto-organize works. Magic Nodes add-on is based on the original script 1.3b 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 discussion about this version of the add-on, you could visit the 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.

Download:

Latest version of the add-on

If you are the first time user, it is recommend that you read the manual written by Rick Parsons:
è PDF manual (currently covers v1.7.6.2)

You could also take a look on my other scripts for MediaMonkey:
Visitors since
2008-04-15

Donation:

These add-ons are donationware. Their development took considerable amount of time, so if you found these add-ons useful and want to help their further development, it would be nice if you send some small donation. You could donate as much as you think that is appropriate using Moneybookers or direct bank wire transfer.

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 script 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. So, it is highly recommended to switch to version 3.1 of MediaMonkey as soon as possible. If you want to test your version of program on mentioned bugs, you could get test scripts from the MediaMonkey forum.

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:


What is new:

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 script stores masks into the MediaMonkey.ini file.

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).

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 if used 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 could be real annoyance 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.