User Details

Username: greaterthanzero
Website: None provided
Facebook: None provided
Twitter: None provided
Soundcloud: None provided
Account Status: enabled
Member since: Dec 12 2009
About greaterthanzero:
(report this profile)

Devices by greaterthanzero

stepArp Version 1.0
Drum Thinner Version 1.0
Blobber Version 1.0
SWAM Thing Version 1.1
Global Transpose Version 1.0
Multronome Version 3.0
note speed limit Version 1.1
Force C Major Version 1.02

Total Downloads: 3,508


Comments by greaterthanzero

Comments

I could technically add a toggle for A Minor, but that would break the minimalist design, and I'd also have to rename the device.

C Minor is out of the question.

This should work in older versions of Live, but has only been tested in Live 12 beta.

Actually, disregard my previous statement. The link in the "URL (optional)" field remains broken, but the "download device" button below that appears to work.

(I haven't confirmed that the file does. Latest version is 13 years old. But you should be able to edit and troubleshoot, if needed)

That's strange for two reasons:

First, the default quantization setting is 16 (the fourth item on the list). If it's resetting to anything, it should be that.

And second, there is nothing plugged into that drop-down, nor addressing it remotely.

If I had to guess, I'd say you've MIDI mapped that control, and Live is zeroing out your CC values (and/or sending note off messages) when the engine disables.

More testing required, obviously. I'm not able to replicate the problem.

If that's what's happening, there isn't much to be done about it from within max for live.

(I'd look into perhaps merging your interfaces into a composite audio device.)

Don't get me wrong, if Ableton gave us access to write automation to a MIDI clip, I'd be all over that rewrite, because I think that could be useful.

But I don't think probability or randomized velocities will help this device.

I technically could, but it's a significant rewritr, and I'm not sure what the point would be (outside of making that warning message go away in Live 11). It doesn't actually affect functionality.

Meanwhile, the change would entirely break the device for everyone in Live 10 or below. So, that's a big cost with little benefit, from my perspective.

I'm so glad someone else has a use for it. I held off on publishing forever, because it just felt too niche. But it's been very liberating for me as a songwriting tool.

It does seem to work now!

Might be worth editing the form so it doesn't specify (.jpg only)...

Regarding screenshots:

The site accepts only JPG. Other sites (Facebook) accept the PNG files that OSX natively captures, so I understand ehere that expectation comes from, but you have to convert them to JPG before they can be used here.

(This extra step has stopped me from uploading a few devices that weren't really that important. Whether that's a good or bad thing, I couldn't say.)

I, too, forget to check Live itself to see if the thing I want to build is already a feature. It's a good learning exercise, regardless. And users can learn from your code as well, so it was all worth doing.

(still, see the "random" knob on the Velocity midi device.)

UPDATED to v1.1

I've been up all night setting ranges for all the new SWAM Brass instruments. Double-checked them all, but let me know if there are problems.

I may decide to reorganize the drop-down menu, and possibly split things up by family. (e.g., a secondary dropdown to select between woodwinds/strings/saxes/brass) It's getting cluttered.

Hey, sorry everyone. I had no idea the ddg patches weren't included with max by default. They were made by a Cycling74 employee, and I can't think where I would have obtained them from if not the official distribution.

Unfortunately, this site isn't great about sending notifications (special thanks to Dan Derks for emailing me personally!), so this has gone unaddressed for three or four months now, and none of you will likely ever know that i'm correcting the situation.

(New upload momentarily. I'll update the version number to 1.02, I guess)

Hey, that download link seems to be broken. Just FYI.

It adds a minimal amount of latency in the note collection phase. There's a [thresh 1] object in play which delays things by 1ms. And there are two of those, though I don't believe the timing of one is dependent on the other's completion. So I would say that there is either one or two milliseconds of known latency added.

For a MIDI drum track, that difference shouldn't be perceptible, but if you're using those midi notes to trigger audio effects, it won't be considered sample-accurate timing.

...but as I noticed your question a full year after you asked it, you've probably evaluated for yourself by now.

@synnack,

I'll run some tests and re-evaluate.


@bootykowski,

"Useless" is relative.

Presets aren't currently stored, no. You'll find, if you try to add that, there are a couple of clean-up mechanisms in play that are going to interfere in surprising and nasty ways. Those will need to be restructured before it becomes viable.

Just a simple example, my patch includes a file called "matrix.png". What are the chances that no other patches anywhere also include a file called "matrix.png"?

Isolated by directory, they can coexist happily. But unfreeze any two such patches for editing, and you've created a file conflict that will never resolve itself without user intervention.

So, maybe I name my files more uniquely. And that'd solve it for sure, until someone builds on my patch and reuses the file. Which I'd totally encourage in any other circumstance, but now?

Technically, that last bit isn't my problem, but it is completely avoidable. Responsible file management means I package the files separately.

We've got a great platform for distributing open source apps, with a convenience feature that discourages modifying each other's code. Refusing to acknowledge it seems the only sane answer.

You'd be surprised.

I hate frozen devices like nobody's business.

@emf,

Max For Live can't tell the difference between incoming notes from your controller vs from your clips. It's all just incoming notes from earlier in the chain. This is a blessing and a curse.

It sounds like you've put the device on your instrument track, affecting every note that reaches the instrument. That's clearly not what you want. Instead, bring your controller in on its own track and put the device there. Use the "MIDI TO" drop-down to send notes from that track to your instrument. Use that same drop-down to send your clips to the instrument from their own track. The effects you place on each source will only affect that source.

------

I've hacked a few versions w/ mappable timing control. Haven't liked any of them yet -- what's your vision for how you would use it?