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

[sadao]

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

I beg to difer . The sister table doesn't contain any duplicate information (in db parlance, it is normalized). The only thing it has is the split artist name (which is not the same as the artist name) and a relation back to the songs table (the songs_id). Note that for briefness sake I didn't note all the fields that are present in the songs table that would not be present in the sister table. There are a number of other similar sister tables that already exist in the MM database (such as 'AddSongInfo' or 'Played'). To the extent possible, I agree with you that one should not be adding tables to the MM database. In this case, it would be worth it. But...

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

... this is all moot anyway. Maybe the Devs will want to implement this. I guess the ease with which this can be implemented depends on whether changes to the songs table are always carried out by the same method/function (in which case it's easy to add the maintenance code for the sister table).

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 .

I'll do that then.

[Risser]

Thanks for your quick reply on the unknown quality. I completely forgot about that node.

I implemented the Comments node as well, as I need to go through and move some of the information I have in comments into the various existing AS fields.

However I noticed that Lyrics are showing through on the comments node. Is that because they use the same DB table?

Just wondering,
Peter

[Pablo]

I beg to difer . The sister table doesn't contain any duplicate information
(in db parlance, it is normalized).

A, B and C appear in both tables. The problem (for my style of programming, at least) is not the duplicate information in itself, but that whenever you add or update a record in Artists you have to also change the sister table, even after defining relations between the tables. That's not the case with AddSongInfo and all the other "sister" tables in the current database.

Anyway, it's all moot right now . But if we could figure out a way for this to work, it would help also with the genre field (for songs who belong to several different genres).

[Pablo]

Thanks for your quick reply on the unknown quality. I completely forgot about that node.

I implemented the Comments node as well, as I need to go through and move some of the information I have in comments into the various existing AS fields.

However I noticed that Lyrics are showing through on the comments node. Is that because they use the same DB table?

Just wondering,
Peter

Peter, that's a careless bug in the script that will be fixed in the next release.

[sadao]

A, B and C appear in both tables. The problem (for my style of programming, at least) is not the duplicate information in itself, but that whenever you add or update a record in Artists you have to also change the sister table, even after defining relations between the tables. That's not the case with AddSongInfo and all the other "sister" tables in the current database.

You're right, the dependencies are more complicated. And as such, this field splitting is less likely to ever see the light of day .

[Octopod]

Pablo,

FYI, i had problem with the function 'FormatRating' that uses 'FormatNumber'. The reason is my XP is configured with french locale conventions and this VB routine is locale-dependent. Especially the french decimal separator is ',' and not '.', so the function returns an 'incompatible type'. I solved the problem by removing the 'FormatNumber' call.

BTW, you could use (automatically according to nodes types or manually) the node qualifier "SortGroup" that would automatically sort the tracklist according to users settings.

@MM Team: is it possible to declare a callback for a text field so it would act as "OK" when hitting enter?

[Pablo]

Pablo,

FYI, i had problem with the function 'FormatRating' that uses 'FormatNumber'. The reason is my XP is configured with french locale conventions and this VB routine is locale-dependent. Especially the french decimal separator is ',' and not '.', so the function returns an 'incompatible type'. I solved the problem by removing the 'FormatNumber' call.

Thanks for the feedback Octopod. It'll be fixed in one way or another in the next release.

BTW, you could use (automatically according to nodes types or manually) the node qualifier "SortGroup" that would automatically sort the tracklist according to users settings.

Yes, that's a good idea. I'm not sure whether to set it automatically or through a qualifier... what do you think is better?

@MM Team: is it possible to declare a callback for a text field so it would act as "OK" when hitting enter?

I fully support this idea . And another one which acts as "Cancel" when hitting esc...

[jiri]

@MM Team: is it possible to declare a callback for a text field so it would act as "OK" when hitting enter?

You are right, this one was missing. In the next release the handling will be the same as e.g. in Delphi VCL, i.e. each button will have Default and Cancel boolean properties. If Default is true for a button, it means that this button is pressed when Enter is, and Cancel means that the button is pressed when Escape is.

Jiri

[sadao]

Pablo,

I think you should add an example to your documentation where one of the masks is sorted without the 'sort by' qualifier: e.g. Rating\<rating|sort order: desc>. While you talk about this in the tutorial, I think most people will probably use your examples as quick references.

My $0.02.

S.

[sadao]

More requests!

-Function Masks: Album Rating\<round(avg(rating))|group by:album>\<album>
-More Child of options: I would like to be able to place a super-genre node just beneath the genre node (well, ideally, I'd like to be able to re-place the genre node but the dev's would have to give 'hiding' ability).
-Loading progress bar: When clicking on top level node it can take 3-4 seconds to load all the tracks into track list and as things are now there is no feedback in magic nodes. I imagine you don't have control over this, but perhaps the devs will be interested in allowing script calling of the progres bar...

if you happen to be bored and looking for something to do...

Only suggestions. Your script is great as it is and does just about everything I want it to do.

[Pablo]

As usual thanks for the tips Sadao! I've been busy lately, but I hope to release an update by the weekend.

- Applying aggregate functions to fields is a possibility. Currently the closest you can get is using sort by:

Code: Select all

Albums by avg rating\<album|sort by:avg(rating)>

But I will explore your suggestion.

- There were restricted options for child of: because the scripting system gave access to just a few of system nodes, but that's been changed in the latest builds so now you can use pretty much any node you want, including genre.

In the current version of Magic Nodes (1.2), the error checking procedure should block the newly added nodes (like genre). This will be fixed in the next release, but you can also do it now as long as child of: is the LAST qualifier (this is due to a bug in the error checking).

- Re: Progress bar. I agree it would be great but unfortunately it doesn't seem to be possible . The scripts can control the progress bar, that's not the problem. What takes very long is the execution of SQL statements, over which the script or MM don't have any control or can gather any further information.

May be there's room to improve the SQL code so that the queries run faster, but I haven't been very successful at this lately.

[sadao]

- There were restricted options for child of: because the scripting system gave access to just a few of system nodes, but that's been changed in the latest builds so now you can use pretty much any node you want, including genre.

Great!

- Re: Progress bar. I agree it would be great but unfortunately it doesn't seem to be possible . The scripts can control the progress bar, that's not the problem. What takes very long is the execution of SQL statements, over which the script or MM don't have any control or can gather any further information.

Hmm... How does MM display the progress bar when loading the track list (try clicking on the artist node)? At any rate, even turning the cursor into the hourglass or an 'executing query' in the status bar would do. My only concern is that right now there is no feedback when a magic node is clicked, until the query completes. The first few times this happened I though the node wasn't working (I have ~30K tracks in my library).

May be there's room to improve the SQL code so that the queries run faster, but I haven't been very successful at this lately.

Does MS Access allow indexing? I haven't used it much so I have no idea. Besides, I imagine you've explored this aspect of it already. Other options are to set up pre-calculated tables, but on this i'd have to agree with you that it just seems like a bad idea .

Thanks for the responsiveness. Looking forward to your next Build .

[Pablo]

Hmm... How does MM display the progress bar when loading the track list (try clicking on the artist node)?

You're right about the artist node... but I have no idea how they do it . May be they somehow query the database in little pieces? Or may be the status bar is not for the query itself but for preparing and showing the tracks?

At any rate, even turning the cursor into the hourglass or an 'executing query' in the status bar would do.

Hmm... my cursor does turn into an hourglass so I'm getting an indication. It's a MM (or Windows?) thing because there's nothing in the script code to produce that behavior, but it happens. In any case, I'll see if there's a way to display a message in the status bar, I haven't looked into that.

Does MS Access allow indexing? I haven't used it much so I have no idea. Besides, I imagine you've explored this aspect of it already. Other options are to set up pre-calculated tables, but on this i'd have to agree with you that it just seems like a bad idea .

The problem is not that access is slow or the lack of tables, but that as long as you start adding qualifiers and, even worse, filters, the SQL queries become very convoluted and far from efficient. For each specific situation, one can write a query which runs almost instantly, but it's more difficult to do when you're combining all the pieces of information given in a mask on the fly .

[sadao]

The problem is not that access is slow or the lack of tables, but that as long as you start adding qualifiers and, even worse, filters, the SQL queries become very convoluted and far from efficient. For each specific situation, one can write a query which runs almost instantly, but it's more difficult to do when you're combining all the pieces of information given in a mask on the fly .

I can see how that might be a problem. I guess it's kinda like auto-generated HTML, it gets kinda messy.

[Guest]

it seems the script doesn't work for me. I'm using 2.2.2 and i get an error mesage: Error happened during script execution:

A script engine for the specified language can not be created.