Help with granular patch
Oct 06 2016 | 12:47 am
Hi all, i'm working on a granular patch for make texture sounds, i've pretty complete my work but some errors occurs sometimes. I'm not really skilled with granular synthesis, to do my patch i watched lots of tutorials, other patches, trying to understand the best i can, for that reason i need help to make my patch work better. I would like someone to check if my patch, to see if there is anything I can do to optimize it, give me some useful tips to improve it. I would like after to transpose it on M4L, And maybe with a little bit of study to transpose the granular engine in GEN~ code. I created the patch so that through a midi keyboard each note corresponds to a piece of sample, rather than control the pitch, I use a keyboard with 32 keys, so the entire length of the sample is divided by 32. To obtain the desired granulation I created a poly~ inside a poly~ , there is something wrong with the management? Sometimes I have problems with the notes, with messages mute / unmute, is there anything I can do to improve the management of the notes? Find my patch attached, I hope I was clear and I apologize for my bad English, I hope someone can give me some advice to optimize my patch.
Thanks in advance and I'm here for any questions.
- Oct 06 2016 | 10:35 pmNo one can help me? Maybe i've not well explained?
- Oct 07 2016 | 8:27 amHi I'll have a look at this over the weekend.
- Oct 07 2016 | 3:27 pmThanks a lot, really glad, your patches help me a lot to develop my project...
- Oct 08 2016 | 12:26 amAlso tuning in.. and curious about what others consider to be some of the best implementations of granular synth to date in Max space (M4L too buy ideally Max solo). There are so many, it's difficult to know the best ones to study for personal builds. Some are very different in appearance and UI, making it even more confusing to know what is essential.
- Oct 08 2016 | 10:44 am@metamax "there are so many". Indeed. Perhaps because (unlike FM synthesis, for example) there are so many different ways to achieve what one wants, with grain-based pitch/time manipulation and with granulation synthesis. Personal faves include Timo's grainstretch~, and JFCharles spectral tools. M4L there's only one choice really (?) - Monolake. But I use these examples as inspiration for my own designs ("Granary"), rather than as tools in and of themselves.HTH Brendan
- Oct 09 2016 | 12:38 pm@observerI've just had a brief look at this, and the first suggestion I would make regarding optimization is to place your filters OUTSIDE your poly~. This patch maxes out my CPU at a constant 100%, and it won't play. You have 2 biquads per voice x 16 voices = 32 biquads; that's gonna be expensive.I don't have a suggestion re poly~ inside poly~, but that is also going to be expensive.HTH Brendan
- Oct 09 2016 | 1:48 pmThanks a lot Brendan! I know poly~ inside poly~ is a lot expensive in CPU but it's the only way i found to obtain the textures i want, I was thinking to translate all the first poly engine in gen~ code and after put it into a poly~, this way spend less CPU it's correct? but i never used gen~ it's a unknown world for me!! Thanks a lot for the filter tip i will place it outside of the poly. What d'you think about the note management? And have you some tips to translate my engine in gen code? something where i can start from...
- Oct 09 2016 | 2:35 pmAnother thing, i would like to implement the visualization of the position for each instance, i simply make a out in poly~ , but it seems to give me just the first instance position, there is a way to obtain the position of each instance?
- Oct 09 2016 | 4:28 pmHi the note-handling looked ok, I couldn't see any glaring errors. As for gen~, you can patch as normal using graphical elements - as opposed to writing code inside codebox. The main objects you'll want to look at are [buffer], [peek] and [mstosamps].There was a thread here recently regarding voice-specific data FROM poly~ (rather than INTO poly~), but I'm afraid I can't remember the thread title. I guess you would have to use [thispoly~] to grab the voice number, and then use dynamic naming and [prepend] to give the data a unique identifier on a per-voice basis. Sorry not to be more specific.Brendan
- Oct 09 2016 | 4:35 pmPSI can post a very simple example of a grain generator written in gen~ if you like . . . .
- Oct 09 2016 | 4:47 pmlike this . . .
- Oct 09 2016 | 4:54 pmDoes translate my patch in Gen~ will decrease the CPU usage? yes of course if you can, it will be really helpful for me to see an example as start point... As you suggested i place the filters out of poly~, now my CPU usage it's around 30% and 60%, not bad, but i think with gen it will decrease a lot (at least i hope).Thanks a lot for your help
- Oct 09 2016 | 8:20 pm"Does translate my patch in Gen~ will decrease the CPU usage?"This is a VERY BIG question. I'm tempted to say: No, not necessarily. I'll tell you what I know/think: everything inside a gen patcher is always "on", there are no bangs or triggers because samples are being processed 'instantaneously' (scare quotes) and continuously. When I'm using poly~ and/or gen~ i always aim for economy. Make the poly~ subpatch as light as possible, whether it's gen or MSP. That means that you can maximise the number of voices available to you, which is, arguably, desirable in granular synthesis. The question you pose above is beyond my ken, and I would defer to Gregory Taylor, Ben Bracken et al to be more specific. Performance gains are a subjective matter, but there are also DSP/mathematical truths that cannot be avoided.Also be aware of 'skills envy' and 'option anxiety' (I don't know the equivalent Italian expression) - use gen if you can/want, but performance gains might be +/-.Again, sorry to mislead you into thinking I'm an expert ;)Peace Brendan
- Oct 09 2016 | 10:34 pmNo problem, you even helped me to understand a little more about gen, at this point I think I'll leave my patch as it is if i'm not sure that translate it in gen will optimize the cpu usage, i think i will translate in a M4L patch, the M4L environment it's good because it allows me to rec clips easily and easily transform in audio... Another problem that i had with my patch is that when i change note in the keyboard sometimes it's not immediate, i mean i press a key the when i change note, first time i press the note it sound the same of the least i pressed, if i press again it changes to the right part of the sample... It has something to do with the mute / unmet messages in your opinion?
- Oct 09 2016 | 10:36 pmanyway "Option anxiety" =) i know what you mean ahahah s
- Oct 10 2016 | 5:35 amOptions.. never too many options. And never too many questions... :)Brendan, the reason I'm revisiting granular is I'd like to sonify changes to image textures using a painting app I'm building. It has quite a lot of visual detail and I'd like the sound to reflect that. I'm just wondering if granular the best approach for complex input (ex. many bristles across many surface bumps). Seems like I need something else to complement gs. Any thoughts on modeling (or even sampling) used in conjunction with granular to generate range of brushy, chalky, drippy, scratchy, splotchy, droplet, glob, splatter sounds? I'm not far off from a serious study of gen~ but until then, I pretty much suck at msp. I appreciate any insight. Cheers.
- Oct 10 2016 | 7:34 am@metamaxI guess it depends on your goal - a distributable standalone, or personal artistic use. If it's the former, then you'll want an economical solution, like FM synthesis, with lots of envelopes. Or QFM (any excuse to throw this out there):If it's the latter, and using your adjectives (except "chalky"??) I would go for sampling + granulation. And as for gen (again), I stand to be corrected but, I don't think there's anything you can do, sound synthesis I mean, in gen~ that you cannot achieve in MSP. Physical modeling and waveshaping, maybe there are benefits to using gen~ but those gains would be pretty specific.Brendan
- Oct 11 2016 | 12:44 am@Brendan Can you help me with the mute unmet messages? i would like to sync the two poly~, what i found in the forum refers to a metro based engine, it doesn't work with my patch, also as you see i have a this poly~ in the nested poly that gives me instance number for unique phase, i don't know if i can use it for mute unmute, or if i can have more than a this poly~ per patch... i'm a little bit confused...
- Oct 11 2016 | 1:40 pmBrendan, thanks. I need to get clear on different types of granular synthesis. I'd love it if some geek created example patches to go along with Roads' book. I agree about Timo's external but it's 32-bit only and some of my graphics work requires 64-bit. I generated some really useful wet droplet splatter sounds almost 'out of the box' with cm.grainlabs~ and it's 64-bit compatible.btw, I mentioned gen~ because it seems easier than msp~. My genexpr skills are improving and I think that will give me more of a running start than focusing on msp objects - or at least, it should improve my understanding of how signals are shaped under the hood.
- Oct 11 2016 | 7:41 pm@metamax - it sounds to me like you are good to go - on both MSP and gen~. The distinction between the types of granulation synthesis, to me, is clear - time/pitch shifting (messing with audio files) and/or granular REsynthesis (new textures/timbres from relatively simple sound sources). Did I mention J. F. Charles' spectral tools? Cuz I usually do, regardless of the thread topic - really good for frequency domain resynthesis. HTH@observer - I can't guarantee that I can look at this before next weekend, but I'll try to investigate further, ok?
- Oct 13 2016 | 3:05 pmNo problems, i appreciate that =)
- Oct 16 2016 | 5:28 pmHey Brendan have you found something? i'm really stuck with that problem... I can't figure how to fix it
- Oct 16 2016 | 10:54 pmActually i've abandoned the poly~ inside poly~ stuff, it's a messy patch and it give too many problems, i will use just a poly and try to play as much as possible with size of the sample to make the granulation i want. The idea is to copy my project and simplify the poly~ engine after that i will retry the poly inside poly, but with a big engine like that it's not possible... Anyway, with just one poly~ mute unmet problems seems to be fixed. Just a question! there is a way to have voices out separate? I had the idea to implement that in M4L version of my patch, the idea is open my instrument in a midi track, and then have, for example 16 ,different midi tracks in Ableton, one for each voice, is that possible?
- Oct 20 2016 | 9:37 pmI would like to have phasor synchronized with the notes in, i mean when note on the phasor~ ramp starts from 0. this is normally achieved with a message to the phase of phasor~, but in my case every instance have a different phase, so i can't send that message, there's another way to do that?
- Oct 21 2016 | 8:21 amJust a quick guess: why not use a single central [phasor] driving all the voices? Then phase sync isn't an issue. I haven't yet looked in detail at your voice-handling . . . .
- Oct 23 2016 | 2:09 amwhat do you mean with use a single phasor~?