NRuleSet Builder - a tool to create custom rules

[DrH]

Bravo!

I have been experimenting with your program and am finding it very useful.

The only situation I have encountered so far is that you do not have not included a number of expressions in your Condition pull-downs that are present in the ExpressionList.tpk file, like:

senza sord.
mute
open
normale

Figuring you might want to look into these (and perhaps more) omissions and thanking you for a great tool,

DrH

[Erufailon]

Hi,

glad you find it useful.

mute is "with mute". The ruleset builder parses the expressionlist.tpk and includes all the techniques that are picked up by Notion3 and adds their friendly name to the lists. Senza sord is not included for this reason, it's just like pedal up. There is a pdup ident for the pedal up technique, but it's not really a technique, it just ends other techniques (pddn), just like senza sord. So there is not reason to create a rule that has the if technique=pdup, it won't do anything. What you can do instead is check against it's negative. So it would be a condition that checks if the pedal is not down. Meaning you need to add the pedal down condition and check the not true checkbox, or in case of senza sord. any techniques (it doesn't just end sord.) it ends and check the not true checkbox.
So they are not ommited, they just don't do anything in notion if you check against them (at least to my knowledge, maybe Astinov will correct me if I'm wrong, and I'll change the app.).
Open is also like this, and normale ends all techniques. If technique = normale also wouldn't do anything.
I hope I'm making sense.

Erufailon

[Jerome Vonhögen]

(...)Swing worker can be downloaded from java.net.
(...) Appframework is also easy to find, for example at http ://java2s.com
(...) I really wish I could avoid this...

Well, to make things a little more convenient, these links should get you to the files more quickly:

swing-worker-1.1.jar:
https://swingworker.dev.java.net/servlets/ProjectDocumentView?documentID=51772&showInfo=true

AppFramework.jar:
http://java2s.com/Code/Jar/ABC/DownloadAppFrameworkjar.htm

(Note: AppFramework.jar needs to be renamed as per the author's instructions in post #2.)

Thanks a lot for the RuleSet Builder, and keep up the great work, Czentye János (Erufailon)!

- Jerome Vonhögen

[DrH]

Erufailon,

I tried your "not with mute" suggestion, and I think I've discovered a glitch in N3.

Simply put, it appears that N3 does not internally recognize special mute markings like straight, cup, harmon, and bucket (all of which I use with my Garritan JABB brass instruments) as actual mute techniques. Therefore, using a "not with mute" condition to re-set to keyswitch 0 parses to being always true for all of these special mutes, which in turn blows them away.

That's why I think you need to include senza sord in your condition list.

Thoughts?

DrH

[Erufailon]

Seems I wasn't clear enough, sorry.

It doesn't matter if I put senza sord in or not, because it doesn't do anything, but ends these: mute stra cup buck hrmn ston stpd.
So even if I put it in and you create an if senza sord. rule, it will not do anything, N3 won't even pick it up. Originaly I had all these in, but I realized that it just creates this confusion. They are not techniques, they just end techniques and N3 doesn't recognize them for this reason. At least this was the case the last time I tried. At first for QL pianos I used a rule somewhat like this: if technique=pedal up then cc#64 before note value 0. This didn't work, N3 didn't recognize Pedal up, because it's not a technique. So I changed the expressionlist.tpk, so in my version it is a technique now, but that's not really advisable, it's better to check against it's negative, because expressionlist.tpk gets changed and overwritten by each update, and if you make a mistake in it, you can ruin your installation.

This all makes sense, since in the rules files you can check against techniques, conditions and articulations. Senza sord (and pedal up) is neither, it just ends other techniques, it's not a technique itself. There is no way to check for symbols in the score through rules, the rules only check if the conditions you specify apply to a note or not. N3 checks the symbols, and apply the appropriate expressions to the notes, but as far as rules are concerned the only thing that matters is the current note's properties. So if you have a note before senza sord, but after with mute, it will have the property 'mute' attached, but if you have a note after senza sord, it will not have 'mute' attached. And the rules only check against this, they don't see the symbol 'senza sord.' They only know if a note has something that applies to it or not. I don't know how else to explain this.

And yes, those mutes are all recognized and are all used by N3. And senza sord ends them all. But with mute is just a general mute. If you want bucket mute, you need to use that and if you want to see if it's off, you need to create a rule that checks against bucket mute. With mute actualy ends bucket mute and all the other mutes. So if you want N3 to recognise all the special mutes and if they are off you need to create rules for all of them, with mute doesn't cover them, ut1s not a catch all mute, it's a separate technique in N3.

[Erufailon]

The new tutorials explain a lot about the rules. This tool does exactly the same thing, except with a gui and only for midi-out.
And a question. I see not many people care, which is a bit surprising because there has been a lot of requests for custom rules. Anyhow, is there a point to updating this tool to use plugin ids and not only midi-outs? I never use them, midi-outs are better for me (able to use x64 host), and this took a lot of time learning java and all that, but I'll get working on updating it to use plugin ids as well if it's worth the time (meaning you guys need it).

[fabiolcati]

Hi Eurafailon.

> I see not many people care, which is a bit surprising because there has been a lot of requests for custom rules.

It cares to me. In my case is for I don't own other libraries than bundled sounds.
So I need to concentrate on one thing at the time.
You've done a GREAT job.
Don't give up.

[4tune]

Yes, thanks Erufailon, I am in a similar boat as fabiolcati (though I own GPO) I have not got around to this yet as am still really learning new things with Notion. I will take look at the tool soon

Cheers!

[Erufailon]

I'm not giving up or anything, I'm just asking, because this has been brought up by astinov and if you look at the code, it was written with the 4 midi-out ports in mind, so rewriting it would be a bit of work, and if noone would use it (as I said, I wouldn't, midi-outs work better for me, just wish there were more than 4), it's not worth it.

[pcartwright]

And a question. I see not many people care, which is a bit surprising because there has been a lot of requests for custom rules.

I'm definitely interested in this tool especially since Notion released details and tutorials about custom rules. I'm probably the opposite of you in that I prefer to use my VSTis in Notion in lieu of MIDI outs. However, I'm not sure a revised tool with plugin specific IDs would be necessary. With the documentation that Notion has provided, would it not be possibe to use your rules editor and then make a few edits to the new rules file to reflect a specific internal VSTi instead of a MIDI output? I'm not much of a tech or computer person (though I've pieced together some customizations of my own to GPO), but I definitely prefer the GUI tool that you've built over the line by line code approach. I don't think a few "manual" edits would be much if a user preferred an "internal" rules file versus the MIDI out rules files.

Thank you so much for your effort in this area; I'm sure I'll have some questions for you as I use these resources more.