use a video card output plugged into some sort of external recorder, then just record in realtime. i'm considering using this random VCR my roommate left here to do this, but some realtime dvd recorder would be ideal. unless you have a serious powerhouse it's kinda ridiculous to put your system through all the realtime rendering as well as recording to HD. although nowadays machines are way more powerful. a few years ago i had a 1.5 ghz athlon with a geforce 3 and the method i ultimately settled on was recording the audio separately to .wav, dumping each frame of the gemwin to a jpg (which on this machine had to be a smaller resolution and TERRIBLE terrible quality), then i had a complex script system to use mencoder and ffmpeg to put the stills together to a video then add the audio. eventually it somewhat worked, took LOTS of trial and error, but ultimately it never captured the true potential of what i was trying to record. recording externally will let you save ALL your overhead for realtime audio/visuals, at as high a resolution and complexity as you machine will allow (and ultimately the recording resolution of the device).
just my 2 cents, i really know nothing about external dvd recorders and have a crappy machine that can't handle the 3d i need it to so i haven't recorded in a while. but here's an example of my old method recording (and if you notice, the sync is off almost a whole beat, it's supposed to trigger changes only when notes are triggered, i got it sync'd but realized after the fact it was off a beat)

another similar video, sync is way better on this one

but ultimately these had to be dumbed down to be able to record via this backwards ass method.
record externally, then upload some HD for us!

Hello everyone.
Im polishing my PD skills and reading a lot about synthesis i stumbled upon additive synthesis and im making my patch to build waveforms using sine waves with this method of synthesis.
The problem i have is i found the default oscilloscope in PD not very good and since im new at PD i was wondering if anyone had the time to explain how to build a decent oscilloscope to make sure my additive synthesis methods are correct.

@slur said:

not realy
in granular synthesis you change the playbackrate of a small block and change the start position

These aren't really requirements for granular synthesis, though; they're just some of the many parameters that can be manipulated. Granular synthesis is pretty flexible and open-ended. This looks to me like some kind of granular time-stretching.

[EDIT]: This message is rather old and the information written rather uotdated.
But Granita still esists

Please see here:
http://puredata.info/downloads/granita-minimalist-granular-synthesis

and download/pull here:
http://gitorious.org/granita

i'm trying to create a message box for a patch i'm working on...

i managed to create this message;

;
pd-granular.pd obj 200 20 comment 0 9 . granular v.0.2

this creates the comment "granular v.0.2" inside the patch called granular.pd.

i need to be able to delete this message and send others instead to certain positions within the patch...

any abstractions you guys know about that could be helpful?

Hello,

I've got a granular synthesis patch that I've tried to build from the ground up. I don't really know all that much about granular synthesis, and I'm having issues with phasing.

If you record something into the patch (by clicking the record box and talking into your mic for 7 seconds, then unclicking the record box), then try and play things back, you'll notice some strange things, especially as you change the "rate" slider. If you record yourself humming one pitch for 7 seconds and then move the "rate" slider around, it seems that the sound goes in and out of phase, hitting several sweet spots along the slider's width. I know this must have to do with the fact that the same little snippet of the table is being played by enveloped, slightly overlapping tabread4's (in the granplay~ abstraction, in the "pd granplayers" subpatch), so sometimes adjacent periods of the wave in the table cancel each other out, and sometimes they reinforce each other. I also know that the number of sweet spots is related to the number of granplay~ objects I use (would these be called "voices?").

If I get rid of three of the granplay~ objects and just keep two of them, setting their offsets (argument $2) to 0 and .5, respectively, the problem mostly goes away, except the result is a lot choppier.

I want a really, really smooth way of doing what I'm trying to do here. I'm thinking that maybe I should go the fft route, unless there's a simple way to fix this patch I've got.

Any advice / help?

Thanks!

http://www.pdpatchrepo.info/hurleur/jake2_granular.zip

@obiwannabe said:

Eventually one has to embrace abstractions to move Pd to the next level. Granular synthesis is a good example, and generally - sophisticated control for polyphony.

That's a bit of a strange reasoning you have there obi. Because i believe it's actually possible to solve whatever you want in different ways in pd. Everyone searches his own way to get things done. Apparently many of you seem to be in favour of abstractions but,as far as i know, anything is doable without them. But i guess it all depends on what you understand by "the next level" (of complexity, of results, of...?).

Maybe one day i'll discover the invaluable advantages of abstractions and start using them, but until then i'll do my -simple- polyphony and my own interpretation of granular synthesis without them.

I got helped with this earlier. What I ended up doing was using a [delwrite~] and a [realtime]. Set the delwrite~ to the longest loop you could want, and then spigot~ in your sample while banging [realtime] when you close the loop, send the output of [realtime] to the matching [delread~] and size an array (samplerate * realtime/1000). then tabwrite~ from the delread~ into the array. Is this sensical?

@alistair said:

... I remember you describing the downfalls of using a commercially produced program against an open source program which is being renewed regularly

Hi Alistair,

I think my point there was actually the *advantage* of the commercial offering vis stability. It's great that FOSS applications are constantly up to date with new ideas and improvements, but this can work against you sometimes. Always be careful in upgrading to the latest versions and try to use the minimal set of units in your work until you know what is "permenant" and what is "fleeting". Some things just die off because their authors move on to ther things and nobody will adopt them to support.

For me it's extra difficult because I write a lot of Pd code for <b> others </b> to learn from, not just my own personal use..

I had a question about Open Music (I operate a Mac) against Pd. Open Music is certainly cheaper than msp (120€(OM) as opposed to the 600$ (msp)), and (so I'm told) has a strong spectral analysis/fft, and a good support system. I wonder if you had any opinions about this.

Sorry I do not know this software,

A few respected colleagues suggested OM to me; another remarked that "Pd is really old, and even quite slow!" - i didn't have time to get him to elaborate, but -
-I imagined he was talking about live concert situation, using acoustic instruments, which is what he and I do; perhaps involving real time granular synthesis, rapid shifting between granular setting , sampling/transposition, spatialisation and circular movement amongst speakers (this referring to the "spat" module in msp). These would be my areas of concern, just now.

I am afraid your colleague is misinformed. It's nonsense to suggest Pd is "slow" in any way because it's old. Software, unlike physical machines has a tendancy to get faster with time rather than slower (because it gets improved). If you look at the source of Pd you will see it's written in rather efficient vanilla C, that makes it run VERY fast indeed. The GUI which is TC isn't so fast, but that has nothing to do with it's performance.

hallo obi,
thanks for the post, I was trying to find a similar post you made, about, er, a month ago when someone (new to Pd) wanted to know comparisons between Pd and Maxmsp (and another prog.). I remember you describing the downfalls of using a commercially produced program against an open source program which is being renewed regularly; i just couldn't find it, it might've helped to've quoted the link...

I had a question about Open Music (I operate a Mac) against Pd. Open Music is certainly cheaper than msp (120€(OM) as opposed to the 600$ (msp)), and (so I'm told) has a strong spectral analysis/fft, and a good support system. I wonder if you had any opinions about this.
A few respected colleagues suggested OM to me; another remarked that "Pd is really old, and even quite slow!" - i didn't have time to get him to elaborate, but -
-I imagined he was talking about live concert situation, using acoustic instruments, which is what he and I do; perhaps involving real time granular synthesis, rapid shifting between granular setting , sampling/transposition, spatialisation and circular movement amongst speakers (this referring to the "spat" module in msp). These would be my areas of concern, just now.