The death of the LFOs

Tue Nov 04 22:29:00 +0000 2003 (Posted by Tim)

Development Activities
2 Comments

It looks like Tap.Tools blue will not be seeing the standard LFO implementation that I dreamed up on this Blog several weeks ago. Here’s why:

First off, it is a royal pain in the rear to implement intelligently. The code is becoming convoluted as I try to implement it, and that is not a good thing.

To top that off, I’m finding that the CPU can bog down significantly because I’m doing things with signals that would normally be reserved for Max control messages. An example: The blue.verb~ external is currently running around 5-6% on my cpu. Turn on the LFO and apply it to the base delay time and the cpu usage jumps to 20%. That just isn’t going to fly.

It seemed like a nice idea to have this stuff all built in. But the strength of max is to wire and modulate parameters with each other – so I think I’ll leave that which is good for Max to Max. Comments?

Comments

hi tim- thats too bad. sounded almost too good to be true… howzabout including the lfo’s, etc in tap.blue and allowing an easy way to hook ‘em up—maybe using named instances of the tap object you want to modulate?

Comment posted by Oliver at Fri Nov 14 13:28:13 +0000 2003

Well, I guess I shouldn’t rule anything out… I’m feeling a bit burned out on the thing at the moment. I’m going to keep pluging away at other things and maybe I’ll come back to it.

Thanks for the feedback – it’s good to know how others think about these things!

-tap

Comment posted by Tim at Fri Nov 14 22:28:43 +0000 2003

Share your own thoughts or comments...

Please log in to leave a comment.

Back to Electoblog Table of Contents