XY x 4 Pad Project

[aliasant]

I have a new version.

I replaced the float smoothers with a lowpass filter instead.
Its a LP filter in green. Not sure how safe it is to use but it hasnt caused any problems yet
and it allows for more smoothing. First I tried using your Andrew. I placed 4 of the float smoothers in a row but it used more cpu. The lowpass filters seems much faster but please test your self.

I did some other minor changes + added some info for some of the main preferences/settings

When I run all 4 dots with automation my Taskmanager say I use about 0% of my cpu.
This is if I go inside the module so there isnt any redrawings made. Pretty fantastic.
If I have the Pad upfront the taskmanager reports about 9% usage and that is very good.
Most my other plugins and builds generally use about 30% when the main gui is visible.

Same if I use my browser and resizes the screen size of it. Seems 30% for screen redraws is standard for me. More or less.

[MyCo]

well... here on my netbook, it uses a complete core, so CPU usage is 50%

[aliasant]

well... here on my netbook, it uses a complete core, so CPU usage is 50%

Ouch. Is this with the GUI visible, all 4 dots moving and the XY Pad module not highlighted?

I took some pictures of my Taskmanager in 3 different situations.

First Pic is; all 4 dots moving and the XY Pad module not highlighted

XY-Pad-Module-NOT-highlighted.png (69.6 KiB) Viewed 1917 times

Second Pic is:all 4 dots moving and the XY Pad module highlighted

XY-Pad-Module--highlighted.png (74.97 KiB) Viewed 1917 times

Last Pic is; all 4 dots moving but inside the XY Pad module

XY-Pad-Module--Inside.png (133.61 KiB) Viewed 1914 times

[MyCo]

yes, all dots moving on front panel... on my desktop PC (Q6600) it uses ~15%, which is quite high. Just to compare on my desktop the default setup of my LoopDrive4 plugin uses ~10% when playing (with all animations).

There is one thing you can see with this module: unselected CPU: ~15% but if it is selected (white border around it) it uses here ~25% !!! So here a new tip: If you've got a large project, don't select anything

[MyCo]

Damn, this schematic is pure chaos since you have animations, here is a tip to half the CPU usage: in the attached image remove the redraw limiter (and all connections) in the red ellipse and connect the ticker to the redraw wireless transmitter...

I can't help you anymore on this, because I don't understand a single bit of this. For me it would be faster to build it by myself instead of fixing any problems in this schematic.

[Andrew J]

Damn, this schematic is pure chaos since you have animations, here is a tip to half the CPU usage: in the attached image remove the redraw limiter (and all connections) in the red ellipse and connect the ticker to the redraw wireless transmitter...

I can't help you anymore on this, because I don't understand a single bit of this. For me it would be faster to build it by myself instead of fixing any problems in this schematic.

It was tidy until Martin got his hands on it

He'll probably tidy it up when he's happy with how it works, and I don't mind helping out with that either (just another opportunity to be usefully obsessive-compulsive ).


The idea was to use the floats as triggers so that it doesn't bother redrawing if nothing is playing. Note also that when playing, the floats are actually dependent on the tick trigger anyway. The strategy here all depends on how important the animation is. My needs were just for the dragging, in which case this approach is most efficient. For permanent playback, your (MyCo's) suggestion is better.

As for doing the movement in stream data, again that depends on whether or not you are prepared to pay for the cpu cycles. I used float mainly because the record/play functionality was an add-on for Martin that I did on the spur of the moment. Stream data would be overkill for my needs.

[aliasant]

Well. First.
When the module is highlighted it uses much more cpu. But thats irrelevant since that will never happen in a plugin.
I took that shot just to show those that didnt know this what happens if you select your module compared to an unselected one.

In real life use it will never use more cpu then it does in SM with the Pad module unselected. And that is ONLY when the plugin is visible/ the plugin editor is open. As soon as you close down the plugin cpu will go down to almost nothing.

If I look at the taskmanager while disconnecting the the dot redraw wireless to stop all redraws I see no difference at all. Steady at 2%
If I instead connect a ticker25 to it I see a small increase maybe up to 3%
But. If Im looking at the GUI I see the big change that Myco talked about. It dropped from about 11% down to about 5%
So thats a good gain. Very good gain.

About the chaos in the schematics. To me it all looks quite tidy. But that might just be in my head. Maybe its actually very chaotic
Are you guys using curved lines in SM?
I dont. Straight lines only. Might be that or?

And Andrew. If you want to tidy it up please be your best obsessive-compulsive.

About doing it with stream. I dont care about sample accuracy for this. You cant move the mouse with sample accuracy anyways. But if you make something else that works Myco. Dont be shy We all have a lot to learn from you.

What I do want is to make that "trail" so that you can see the path you are making when recording a new one for a dot.
The dot should leave a trail after itself so it is easy to get back to were you started. That goes away when the recording is done.

[bootsy]

cool shit

[aliasant]

OK. Made a bunch of fixes + added the path line.

One problem with it though. It only works if the Offset ( I renamed it to "Shrink area by Grids" and placed it in the properties) is 0 When offset is used the pathline is also offset. Andrew..... You the man to fix this. You did the offset thing and understand how it works so you the guy that knows whats wrong

I also cleaned it up a bit + managed to cut even more cpu.
Every dot had its own redrawer and that is quite unnecessary so I removed them all and placed a single one after the dots.
Now its cpu us is down as low as I think it can get. But feel free to prove me wrong

Another thing that was wrong was that the new Green lowpass filters that I added needs a 25 tick which ment that even if a dot was not in play mode it still had a tick going thru it and that made it so that when recording a new move it would record ad 25/sec even if the mouse wasnt moving. This might be a nice thing if you are making rythmical moves or for some other reason like to record pauses. I changed it however to only record when mouse is actually moving. Maybe there needs to be an option here. A switch that lets you choose the way you want to record that dot.

Andrews Recable XY Pad 8.osm

(110.12 KiB) Downloaded 136 times

]

Update: I did some more cleaning by putting all the (not dot dependent) keyboard commands and mouse commands
in a single module with wireless going out. Works fine. I think it might even save more cpu.

Andrews Recable XY Pad 81.osm

(106.72 KiB) Downloaded 182 times

[MichaelBenjamin]

looks like flies, very nice
cpu ~7-9% here

[infuzion]

Andrews Recable XY Pad 81.osm

They look like fireflies dancing!

[Andrew J]

Wow this is looking much cleaner now! And what happened to the CPU meter? It's hardly reading anything - well done sir!

One problem with it though. It only works if the Offset ( I renamed it to "Shrink area by Grids" and placed it in the properties) is 0 When offset is used the pathline is also offset. Andrew..... You the man to fix this. You did the offset thing and understand how it works so you the guy that knows whats wrong

OK, fixed that quite easily. See the Reduce Area module inside Dotted Path Line.

Andrews Recable XY Pad 82.osm

(106.59 KiB) Downloaded 263 times

Another thing that was wrong was that the new Green lowpass filters that I added needs a 25 tick which ment that even if a dot was not in play mode it still had a tick going thru it and that made it so that when recording a new move it would record ad 25/sec even if the mouse wasnt moving. This might be a nice thing if you are making rythmical moves or for some other reason like to record pauses. I changed it however to only record when mouse is actually moving. Maybe there needs to be an option here. A switch that lets you choose the way you want to record that dot.

I like the way the rate/smoothing works and I think it would be a good idea to also allow recording in the mode that includes the pauses. That could be very useful for some applications. Not sure what to call the modes so they make sense - perhaps call one "free draw" and the other "timed draw"?

-Andrew

PS - Sorry about the couple days of silence, had a very busy weekend.

[aliasant]

Ill have a look maybe later this week.

I must say it turned out better then I had hoped for. Much better.

Thanx for the fixes Andrew.
And to everyone else. Have fun with the "fireflies"

[TheAudiophileDutchman]

Great stuff

Runs as smooth as a baby's bottom

[aliasant]

There is one little thing that wasnt as brilliant as I first thought....
I used the 02 keyboard as the Right Mouse down. Wasnt to smart since that command is active all the time. Meain that whenever you click you right mouse the function will execute. In this case if I, in my host right click on a track or what ever the path of the selected dot will show. Should probably change that to right click down primitive instead.