Paolo Piaser

I've encountered a weird behaviour. If I have two gen patches with the same exact code, their location influences the CPU usage. The one on the right is always faster (less CPU expensive) than the one on the left, almost half. 

Is it expected or am I missing something? 

I've encountered a weird behaviour. If I have two gen patches with the same exact code, their location influences the CPU usage. The one on...

gen-patch-spacial-arrangement-different-performance

Gen patch spacial arrangement = different performance?

Jazer Giles

Five oscillators are phase coupled via the sine of the difference between each phase and the average phase leading to chaotic detuning and distortion. A running average is recorded so the calculation can be made with a delayed value to simulate non-instantaneous coupling between the oscillators.

KuraOscSynthExample.maxpat

Five oscillators are phase coupled via the sine of the difference between each phase and the average phase leading to chaotic detuning and distortion.  A running average is recorded so the calculation can be made with a delayed value to simulate non-instantaneous coupling between the oscillators.  

Five oscillators are phase coupled via the sine of the difference between each phase and the average phase leading to chaotic detuning and d

-patchshare-coupled-oscillators-based-on-the-kuramoto-model

Thank you for this! Of all the so-called chaos synths I've come across, this might by my favorite.


[patchShare] Coupled Oscillators based on the Kuramoto Model 

ShelLuser

No, manuals aren't for wussies these days anymore, they're for 

. There's a reason why we can access the reference section right from within our patcher window.

Anywhoo...  My browser "soft favorited" the 

 because I often refer to this on Reddit (no, not RTFM commnents; while explaining the issue at hand and providing references to how I would solve things).

I mean, even the gen~ reference page only lists the gen tutorial ("gen topic") in its "See also" section yet 

More seriously though: this seems like a major oversight to me. Yah, gen~ 

 huge (still is!), but ... [gen] can seriously help you to avoid having to use [defer].

Hi gang!

No, manuals aren't for wussies these days anymore, they're for pro's. There's a reason why we can access the reference section...

why-is-the-gen-reference-page-burried

Why is the [gen] reference page burried?

Yonatan Rozin

I've spent the past few weeks casually working on a Max port of the lovely Pink Trombone (

) vocal synthesizer, which hopefully some folks on here are familiar with. I suspect there's tons of potential for procedural, real-time speech synthesis in live performance, and Max seems like a much more fitting context than the browser to make it happen!

Anyway, I've got a working version that's polyphonic, so you can control an entire Pink Trombone chorus. The only issue is that when using more than 4 voices simultaneously, my CPU usage occasionally spikes above 100%, and this is on a relatively good computer. The JavaScript code I ported this from can handle as many as 8-10 voices with no issue so I'm surprised the performance inside Max is so much lower. 

The synthesis is done inside 2 [gen~] patches per poly~ voice, one for the glottis and one for the tract. I'm no gen~ expert (genExprt) by any means, so I'd absolutely appreciate it if anyone with more experience with gen could have a look and identify any potential issues or improvements.

Simply enable audio and adjust the dials to simulate dragging the tongue and constriction around in the original GUI. You can also draw the target tract diameters manually in the [waveform~]. The aspiration noise might not load but the rest should work fine.

If anyone has any information, it would be so greatly appreciated.

gen-for-pink-trombone-port-help

[gen~] for Pink Trombone port... help!

Martin D

I'm using GenExpr for the first time, and I have a strange issue.

I have a function with three input parameters that should return the value of input 1 or 2 depending on the value of input 3. Returning the parameter variables directly causes the conditional return to never happen, but it does work if I reassign the inputs to a new variable and return that instead. 

Meaning I am able to get it to work, but I don't understand why this is, so I wanted to post here in case someone knows something or it's a bug. I haven't found anything similar mentioned in docs or other posts. FYI I'm working in Max For Live, but I've had no other issues that I know of. Thanks.

I'm working only in Max For Live so a video was faster. To the right is the value of [out3] of [gen~] in a different window. 

GenExpr - func w/ conditional returns fails to return input variable unless assigned to new variable

genexpr-func-w-conditional-returns-fails-to-return-input-variable-unless-assigned-to-new-variable

vichug

This is not such a big deal, since you can give a default value to a gen param as a first argument and other [param]'s attributes should work ; but apparently if you give a default value to a gen [param ] operator using the "@default" attribute, it doesn't work ; the param won't have the value you've given it as a default. Attached is a very simple example : if you click on the yellow arrow on the edge of object box in edit mode, then go in "attribute" tab you should see that "aparam" is set to 0 and "anotherparam" to 1, whereas they should both be 1 because i used the @default attribute for "aparam". sorry if this is a bit tedious

gens-param-operators-attribute-default-doesnt-work

That's been logged internally as a bug now (ticket #9897 for whatever that's worth).

gen~'s [param] operator's attribute "@default" doesn't work

michelefiori

I would like to work starting from the patch

contained in: examples / jitter-examples / gen.

-- Can you tell me where does the mathematical formula contained in gen?

-- what other mathematical formulas I use?

-- it is possible to obtain an output of a matrix retaining the differentiation of colors,

so as to be able to use the matrix to enter additional filters?

Many thanks to all those who want to help me

hi,
I would like to work starting from the patch 

 contained in: examples / jitter-examples / gen. 

-- Can you tell me where does the mathematical formula contained in gen?
-- what other mathematical formulas I use?
--  it is possible to obtain an output of a matrix retaining the differentiation of colors,
 so as to be able to use the matrix to enter additional filters?

iterated-function-systems-2

Iterated.function.systems

analogue01

I really like the sound of the ola.granular patch in the gen examples and would love to adapt it for my own uses. However, I'm not yet very good at reading gen code. Can someone help me undertsand what's going on?

Specifically, I/m wondering why I get clicks/artifacts sometimes when frecency is low and the density is high (and also sometimes when there "ahead" param has a large value). I can still hear the windowing working, too... hmm

I really like the sound of the ola.granular patch in the gen examples and would love to adapt it for my own uses. However, I'm not yet very good at reading gen code. Can someone help me undertsand what's going on? 

Specifically, I/m wondering why I get clicks/artifacts  sometimes when frecency is low and the density is high (and also sometimes when there "ahead" param has a large value). I can still hear the windowing working, too... hmm

I really like the sound of the ola.granular patch in the gen examples and would love to adapt it for my own uses. However, I'm not yet very 

ola-granular-help-me-understand

The way the OLA (overlap-add) examples work is by using a kind of look-ahead buffer to write the grains into, which is constantly read and erased. Every time a new grain is spawned, the waveform of the entire future grain is written into this buffer, using overlap-add (so that other future grains are not overwritten). This all happens in the codebox. It's a gen~ patcher, so the codebox runs on every sample of the real-time audio process. It first checks whether on the current sample, we should spawn a new grain. Then it has a for-loop to write each successive sample of the grain, including computing its window, its content, the stereo pan, etc., and where in the overlap-add buffer it should be written. The parameters  specify the density of grains, their duration, and other properties for the synthesis of each one.

A separate process continuously reads out the result of this buffer, erasing as it goes (a bit like a tape head). This is the max patching code to the right of the codebox.

The clicks when density is high and frequency is low (duration is long) will be because of overloading the audio thread in this case (making dropouts). There's lots of different ways of writing granular synths, and OLA is just one of them. The gen~ examples are particularly well-suited to the use of very short duration grains. As the grain duration gets bigger, there's a higher chance of it causing a dropout, as it is trying to compute and write a large number of values within a single audio thread buffer (computing the entire grain in one shot). For working with longer durations you'd probably want to use an algorithm that keeps track of active grains and synthesizes them in chunks as time passes instead. The code for that would be longer and harder to understand, which is why I thought that the simpler one-shot OLA method would be better for the gen~ examples folder.

Hope that helps!

I don't suppose you have any references for the algorithm you describe in the latter half of your reply?

It's basically the same as a note allocator connecting two parts: a note/grain scheduler, and the note/grain algorithms themselves. 

For synchronous granular, the scheduler will be something like a counter or phasor, triggering a new note each time it cycles. For asynchronous, you could use a probability test, e.g. [noise] -> [abs] -> [< probability/samplerate], where probability is a [param] representing the chance per second to spawn a grain. In both cases, the output is a single-sample trigger to request a new note/grain.  

For the note/grain events themselves, you could do them as grainplayer subpatchers/abstractions, with a bunch of them in the gen patcher (this defines your maximum polyphony, or maximum grain overlap). Each event will have an envelope player, driven by some accumulator such as [counter] or [+=] routing into the envelope function. You can use the position of this accumulator to check whether the note/grain is "busy": that is, if the accumulator position is greater than zero and less than the grain duration. 

For the allocation itself, one way I have been doing this is to pass the new event trigger to the first grainplayer subpatch, and internally, if the note is busy, it passes the trigger back out, and on to the next grainplayer subpatch. If the grain is not busy, it will reset its grain counter to zero and set the grain parameters, thus starting a new grain.  

The outputs of all the grain subpatchers are then just added together and output. 

Thank you that's a good explanantion I'll give it a go. 

ola.granular help me understand

Recall the Coll

Hello, I was wondering if there is a way to normalize in gen~, like the normalize~ object works.

normalize-in-gen-like-the-normalize-object

Normalize in gen~ like the normalize~ object

jvkr

As I was writing quite a bit of genexpr script recently using an external editor, I created myself a tool that makes it easier getting that script inside max from the editor. Maybe it is helpful for others too.

This tool consists basically of a max patch named genitive as well as an abstraction. These are all the required elements: 

https://jvkr.nl/public_downloads/max/genitive_240425.zip

And this is a video explaining how it all works: 

As I was writing quite a bit of genexpr script recently using an external editor, I created myself a tool that makes it easier getting that...

Cycling '74 Forums

sorry but irrepressible: gen~ like a FPGA in an ocean full of systemic rogue waves :-) oups

Love it, thanks a lot for this. Perfectly fits a research that I'm doing.

Hi gang! No, manuals aren't for wussies these days anymore, they're for pro's. There's a reason why we can access the reference section...

@ YONATAN ROZIN thanks a lot. Maybe you can upload the external files to a webhoster (google or dropbox)?

I forgot about the code tab, thanks for reminding me. I'm still new to max. Yes, the 'return' should definitely not be omitted. I'll...

@martind it's working here on 8.6.2

I recommend this paper on fractal flames https://flam3.com/flame_draves.pdf There you will find many possible formulae to use in the...

help->examples->gen

Thank you very much for the detailed reply.

Thanks for the pointers @Graham. Good to know about VS Code. Concerning the automatic reloading, that doesn't seem to happen here, but I'll...