Granular patch problems: distortion and MIDI control
Apr 06 2013 | 11:23 pm
Hi, I have a couple of completely unrelated problems with my patch. Here, I am trying to make a live interface and workstation for my second year of my music degree, and it will include five copies of a granular patch I have made, each of which will be selected in order to control. Right now I am trying to control two parameters simultaneously, using two ctlin objects, which proves difficult as they conflict with each other. I feel that there must be a more efficient way of solving this rather than having a ctlin for every parameter, as I plan to make another 4 copies of the granular patch, meaning 50+ ctlin objects for a few midi knobs. My second problem is the granular patch; the playback of sounds yields a horrible distortion, more so with smaller grain intervals. This is due to a very audible click at the start and finish of every grain. I made an amp envelope (trapezoid~) for each grain, which even when given a long attack, does not seem to get rid of the click. Also, it seems that the 'copy compressed' function doesn't include bpatchers, subpatchers, etc. so I've pasted all five. Your help would be greatly appreciated!
Granular
pGrainPatch
pGrainVoices
pPlayback
- Apr 07 2013 | 11:44 amHi Can I suggest you zip/compress these numerous files; some may find the process of downloading and archiving numerous patches a bit laborious, which will deter us from assisting.Copy Compressed will/should copy subpatchers.Brendanps not sure I grasp what your midi cc issue is, can you clarify?
- Apr 07 2013 | 12:08 pmThanks for the reply. I probably should have thought to compress the files before, lol. Ah well. Sorry if my explanation was a bit off as well. I was rather tired. I am using a BCR2000 controller, sending MIDI messages to a ctlin object to control several different parameters on currently one granular synth. I use the route object to route different controller numbers to different parameters. I have duplicated this so that I can control two parameters simultaneously, however, one duplicate always takes priority, resulting in conflicts. The patch itself should explain this more clearly.
- Apr 07 2013 | 1:30 pmI'm getting continuous errors from this: "times~ doesn't understand bang".MSP (~) objects don't need bangs to function, and I couldn't track it down in any of the main/sub patchers. And it crashes Max; you seem to be sending values plus high speed bangs via send/receive; not sure this is either healthy or necessary. Does this patch work ok for you, as posted here?Brendan
- Apr 07 2013 | 2:17 pmI noticed that as well, which is strange because I have yet to use the times~ object in this patch. I'd imagine that it's part of another default object. My patch itself does work for me at the moment, although if I leave Max running idle for more than 20 minutes or so, I'll often find that it has crashed on its own accord. I guess it's likely that times~ is part of the problem. I'll look into reducing bangs and making the sends and receives a little clearer. Do you have any advice on how to go about doing this?
- Apr 07 2013 | 2:32 pmJust realised that times~ is just the multiplier object *~. I'll look into which one is causing the problem.
- Apr 07 2013 | 2:34 pmIn complex patches trigger order is of paramount importance - you can impose a more logical and dependent algorithm.Use [t] or [trigger]. For example [t i i] will split a single number stream into two, with right-to-left (outlet) precedence.Brendan
- Apr 07 2013 | 2:47 pmThanks, right to left order is something I often forget! I have managed to get rid of the Max error message by simply putting a float number box after a receive, which stopped the incessant bang message. Unfortunately I still can't get rid of the distortion, and can find no explanation for it at all. Here is the updated patch.
- Apr 07 2013 | 3:11 pmHere is a simple (primitive?) grain player, check that yours follows the same basic algorithm (if you are also relying on the [line~] object)HTH Brendan
- Apr 07 2013 | 3:57 pm
- Apr 07 2013 | 4:28 pmMy patch runs in a similar way, but has 32 overlapping grains, each with a variable duration. I tried using the cosine envelope which gave a similar amplitude modulation-esque distortion. I've tried to use your patch entirely as the grain generator, but it only seems to be able to play one grain out of the 32 available, and is not very stable.
- Apr 07 2013 | 4:49 pmregarding the midi issues, make sure you don't do things like what you're doing with the ctlin output wiring; crossing the wires like that will mess up when you switch controllers. I'd go straight into [pack] and then do zl rev instead.
- Apr 07 2013 | 6:43 pmThanks Wetterberg. It now works fine. Thanks a lot as well to Brandon. I managed to successfully replace much of the grain patch using your system. I'll credit you in the patch notes.
- Apr 07 2013 | 7:35 pm"I'll credit you in the patch notes"Good people always do, and it appears Wetterberg provided more focused assistance than I.
- Apr 07 2013 | 7:38 pmPsSo your amplitude modulation sideband issue is also solved?
- Apr 08 2013 | 2:14 pmYes. It appears that my method of triggering grains using Max messages rather than signals proved very unstable, especially with 32 grain generators. Sample & hold processing seems to run a lot more smoothly and ensures that the envelope also works, allowing me to revert back to the trapezoid and have adjustable attack/decay. Thanks again, Wetterberg and Brendon for your time! I'll post the finished patch in the community section when it's finished. I hope to get more involved in the Max community as time progresses.
- Apr 08 2013 | 2:37 pmIf you search YouTube for "fCast" you'll find an old granulator toot of mine. And most of my replies and questions on this forum relate to granular playback/synthesis.Good luckPs you must check out names like Wolek, Sakonda, Robert Henke, Timo Rozendal, grainstretch and grainfreeze.
