EZ Math

[tiffy]

deleted

[RJHollins]

ah ... ok

Using the lead STRING input does re-calculate. [as expected]

I was changing values on the modual directly, like the [.5]. That is not updating [thought that it would/should].

[tiffy]

deleted

[RJHollins]

It seems the 'knob' value [displayed on the PRIM] is the only value control to adjust numbers. Entering data directly on the EZMath prim [using its' edit box] is not acknowledge. Maybe it has always been this way, but I've just noticed this behavior.

It's not my place to say how your module should work [obviously] .... but I would rather enter values directly into the PRIM edit box ... and not try to use the knob to scroll to a specific value.

just my 1/4 cent

[Perfect Human Interface]

PHI, hope you don't mind.

I purged whatever I could purge in there and also altered it so that the module now use approximately 12 parts less.

Not at all. I'll take a look. Thanks for taking the time.

Yeah, first things I noticed are you didn't connect the edit box properly, and there's a slight visual bug when you resize it smaller now that I had accounted for (purely cosmetic but things like that bother me ). Also I note you didn't purge the knob or the properties edit box, and you forgot to update the properties window layout.

I like that you used a "get at" instead of a selector full of individual strings. It's not apparent to me what the bus is for on the operators though.

[tiffy]

deleted

[RJHollins]

The 'purge' optimization, like so much of programing seems to have its' learning curve. Without doubt, my schematics go through several 'cleaning' stages as I experiment/test ideas and concepts .... all while learning ... hopefully

Heck ... it wasn't till recent that I got the hang of 'synchronized' modules I use to hand edit/modify/re-arrange, every one manually.

Purging, in particular, seems a bit tricky since this could introduce unforeseen/untested errors to happen ... again ... I can do these on my own without additional help

It would almost seem that 'specialty' module [like EZMath], because of the design flexibilities, would require added considerations when actually putting the design work-flow together. Basically, a re-fined multi module ... this is NOT how my projects start out, for sure. In fact, it could be several revisions, insights provided by other members here, or a complete re-think of a operation that can make a 'better' procedure. In some cases, it's what forced me to add RUBY into aspects of my projects. I don't know if that improves the optimizations or exported file-size, ram usage, etc., but if it makes it easier to follow and modify a project, and minimize errors, bugs, waste ... that can be good.

I'm following along to learn, so thanks for keeping the 'right' attitude and to the experienced programmers for sharing insight and strategies.

[Perfect Human Interface]

Oh I forgot to mention, you also put the help into another module with intention of purging it, but you can't do that since the pop-up help will then only work for that purged module, not the intended upper module.

1) "Knob not purged" - done on purpose since schematic would malfunction when exported with purged knob.

In my original design it does not malfunction, same for purging the edit box. As Nubeat explained earlier in the thread you can use another prim to hold the value if you're going to purge something like that.

2) "Properties Edit Box" not purged - not sure what component in the schematic this refers to ??

Sorry, I meant the drop-down selector in the properties. I wasn't thinking when I wrote that. Nubeat mentioned properties GUI items should be purged so I took the time to put it into a purgeable module.

6) The "Bus Create" component combine all the inputs from the individual "Operations" into one Bus (similar as the original Selector did) which in turn connect to the input of the "Bus Extract" component which then function as a "Selector" to select the individual "Operations" (Thus, together the "Bus Create & Bus Extract" components function as a unit in the same manner a "Selector" component does). The "Index Selector" component does exactly the same for the "Bus Extract" component what it did for the original "Selector" component, supplying the Index values to the "Bus Extract" component to enable the selection of each individual "Operation".

I understand that this works but I don't understand the reason for the change over just using the selector.

I agree, every schematic uploaded should be perfect - but I am still learning (newbie & human).

I am too of course... but that's why I can't agree with the first part of your statement. I do this out of necessity. I can always do my best to make things both correct and not unnecessarily wasteful, but that's all I can do. If Flowstone projects were only worth creating if they were done perfectly I would never make anything, because I simply couldn't. And if I upload something here and end up learning more from others' feedback than I contribute something useful, I don't see what's wrong with that. I will also point out that we have another website now where "highly refined" projects can be shared...!

[tiffy]

deleted

[Nubeat7]

I wasn't aware that Nubeat 7 had mention that a specific component inside a purged module would still keep the setting

after! not inside a purged module, all what is purged will be deleted, just take one int prim for the selector and one float prim for the value as last primitive before the operation module, and you can purgeable all things which are before, the optimal should be that there are only left one mgui and the operations module all other things should be purgeabled, you should also get rid of all the wireless links which link to nowhere after exporting - i don't know how FS does handle dead links, also when i never had problems with dead wireless links i always try to avoid them..

about the help, the help should be in the first level, so only the text of it can be purgeabled, otherwise the standard help text will be shown