[Share] Sev by Katsuhiro Chiba

[stringtapper]

I have just posted a Max for Live port of Katsuhiro Chiba's instrument "Sev" on maxforlive.com.

I have had a lot of fun with this thing in the past and it was the inspiration for my FM Randomizer (and much more sophisticated than it).

Description:

It spits out randomized notes in tempo based on a scale. The control section lets you: 1) define the range of the scale; 2) set the envelope of the notes; 3) apply delay and detuning; 4) set volume and probability (ie how many notes occur). It's a fun little device for creating beds of sound that don't sound as static as loops.


Thanks to Katsuhiro Chiba for letting me share this port and for making the thing in the first place!

Have fun!

http://www.maxforlive.com/library/device.php?id=170

EDIT: I screwed up and posted version of the patch that depended on an external patcher file. I just uploaded the right one that should work now.

[zigzag]

Brilliant! Many many thanks for this...
Do u think it'll be easy to turn this into a midi effect?

[stringtapper]

I'm going to look at adding midi output since it's been requested by a few people already.

Also look for an update very soon that cleans up the code and fixes a couple of things.

Other future enhancements are a waveform chooser to increase the timbral variety.

[slow riot]

thanks for sharing. I really love this guys patches. Autumn is also great.

[stringtapper]

Autumn is also great.

In the works…

[stringtapper]

Updated to v1.0.4. Cleaned up the transport section so it should run more reliably. Haven't had time to work on a MIDI output feature, but it should happen eventually.

Sev 1.0.4

[broc]

Many thanks for making this device available in M4L. It's a great example regarding sound and graphics.

Just a note on transport sync:
As mentioned elsewhere, observing 'is_playing' delivers at start the sequence 1-0-1.
This may lead to unwanted effects in some situations.
So personally I'm using [plugsync~] instead which sends a clean 1/0 on the left outlet.

[stringtapper]

Thanks for the tip broc. Yeah I'm thinking I might have inadvertently introduced some timing issues with the new scheme. I'm going to look into using [plugsync~] for Sev and Autumn.

[broc]

Please note that you need [plugsync~] -> [change] to prevent repeated sends.

Also, maybe the timing with [phasor~] could be replaced by polling transport with a quantized autostart metro, as commonly used for step sequencers to ensure perfect sync with Live.

[stringtapper]

Please note that you need [plugsync~] -> [change] to prevent repeated sends.

Also, maybe the timing with [phasor~] could be replaced by polling transport with a quantized autostart metro, as commonly used for step sequencers to ensure perfect sync with Live.

Hmm, that's similar to the old method that I just replaced. It polled a [transport] in conjunction with Chiba's [p tempo] subpatch with the [phasor~]. Do you have any specific examples in mind regarding step sequencers using the scheme you speak of? Thanks.

EDIT: I see the [p transportation] patcher in the live.step help file looks like a start.

[broc]

Yep. Instead of '@autostart 1 @autostarttime 0.' you can also use '@active 1'. I find the next to last outlet from transport most useful as it delivers a continuous tick counter from which you can calculate different time intervals and counters by division and modulo (1/4 note = 480 ticks).

[stringtapper]

Ok I was able to completely remove the [phasor~]-driven timing scheme simply substitute a [metro]. All the [phasor~] method was doing was generating a constant 16th note count to send to the randomizing algorithm. The [metro] seems to be much more in sync now. Also I'm using [plugsync~] to set the trasnport state as broc suggested.

Sev 1.0.5

[broc]

I think the tempo patcher can still be simplified, eliminating the need of init/reset actions.

<pre><code>
----------begin_max5_patcher----------
412.3ocwT9sSCBCEF+Z3onoIlnI3rsjAad074vrX5ftspPKBk4zk8taaATlh
ajrE7l9mudnmuyu1xNWG3B4VVADbO3QfiyNWGGqjQvodtCLktMJgVXCCJXuI
W7LzqZIEaqxJeE.GzHlQUQq4hUOkyhTU6MlfGg7zwPLc9SLsDzHDXd82HJS4
hDlxlDRs3RoPUv+fYzvlu7qXkkplfw0pURp2yXUoDxE5j2r+7XqM0V+VeXqs
WPSswCeHmSSflE165ZZ7NOfbm1wndPDeeKQB+OIBYPHhJmJJxj4piPERfEJH
60DL4RRkoGiJde0sLQR+iAcEUm7DOH7LkoxkfYZGwx2PSzOtDfYuVREJMJpl
QiT7M5wmj3gHKoCPCw0vETwpN41jfKK3pxbOdDNs5GRgMscW83NKSzuqiwMo
LRllxDUGWWqOntADkHidocsXSELgK94ugs10neXAVHKyiZHYCz.e63XVghKn
JtTzJH7AwrlGGyDsMeJONSpMXsG.y6j180RlrEdBGQFTG42CFMdPcDoGNx+L
bjdxd2OAPPO0F.
-----------end_max5_patcher-----------
</code></pre>

I've also found that BPM control can be removed from the whole patch using tempo relative timing.
For this in the 'delay' subpatch, object [expr 60000..] must be replaced by following objects.

<pre><code>
----------begin_max5_patcher----------
320.3ocwSErSCCCC8b5WQTNhFSMcaLD2feCzDJqwiETpyTiKTXZ+6zj1Biow
TQCAWpqe1NumeQYaBSrzUCdA+F98bFaaBiEgB.rtblnPUmaU9XaBDdws7Iwn
1RDTSQ3K3oimOqGdihxWavGenDxo1SWlMab5Htb10gvj4wjl+4K5lAqJLnEn
HMYcfqbH4MuAALYZyLezqqh5aV1g1BQutAZoTrx5TMz2yfQGkZi7uTJ1i.TU
DmPbaoQY424rZQn5tjjvmQmmyznAcA387o3.rmzrPXt7z1i7WwdNpyb0emyP
kJzaUDvQGAOqrUfmW3GfKMIMFxl9uYSxI+.eJd.BqAO7oVbEC3e077tpx7d5
6tT3etiZvSFTQFGtWOAEsWSqMZMDq2utEF8FmAoNMvWbzaxgJoCn6azzYHol
jcIuCT6rTTG
-----------end_max5_patcher-----------
</code></pre>

So finally, [plugsync~] is not needed anymore.

[11olsen]

i checked this out a while ago and instantly thought this has to be modded to a midi outputting
device. but i'm busy with other things.. nevertheless a great device mr. stringtapper

[stringtapper]

@broc: Thanks so much for the streamlining. I figured with Max 5's time value syntax that a lot of the original timing in this instrument could be simplified, I just didn't know how to do it! I've put this into a 1.0.6 update now.