Hi all, I'm studying Pd since some months. I'd like to have advice on the best workflow from more experts. I mean, I create a whole composition with Pd, exploiting several different sounds, each of them playing in the proper slot of time. After that I'd like to load each "part" in my DAW (Reaper), to make some final editing, FX and mastering. Do you follow similar flow? If yes, which is the best way for doing that: save all sound created with Pd in several different audio files and load each of these in dedicated tracks? Or other better ways? Thanks.
-
Suggested workflow
-
@bobpell Hi! The way you just described is totally valid, it's probably how most people do it.
Another way to do it, is with plugdata, a Pd VST3/AU/LV2/CLAP plugin that runs in most DAWs. It's based on pd-vanilla and should be compatible with it for 99%, so you could create patches in Pd and then load them into plugdata to record them. Or you can create your whole project inside plugdata as well, if you want.
I'd say the advantage is that the effort to go from Pd to audio is a bit smaller that way. So if you make a recording in Pd but are not satisfied with it yet, it's less of a hassle to re-record it. And you can also use the DAWs automation to change values in Pd, or get tempo information from the DAW.
The disadvantage is that plugdata is still in development, and as such it's not completely stable all the time.
-
Hi Tim, nice to meet you! Thanks for the answer. So I got a first correct approach. As far as Plugdata is concerned, I'm quite keeping tracked on it, already tried to test some very simple patch in Reaper, both under Windows and Linux. And I like it so much
But I'm a noobie, so not all fully clear to me about it's use.
Two scenarios you quoted:
1 - full project inside Plugdata.
If I put it as a VST/CLAP... in one Reaper track, I don't know how to separate the single sounds on different tracks, if still possible.
2 - single parts of the project (in different Plugdata patches) opened each in a single Reaper tracks: how can I keep shynchronized them? In the whole project I have a "complex" timer that should drive each sound generation block.
Sorry if I'm talking non-sense and thanks again -
@bobpell said:
If I put it as a VST/CLAP... in one Reaper track, I don't know how to separate the single sounds on different tracks, if still possible.
Reaper allows sends to be defined based on subsets of the source channels.
2 - single parts of the project (in different Plugdata patches) opened each in a single Reaper tracks: how can I keep shynchronized them? In the whole project I have a "complex" timer that should drive each sound generation block.
DAW timeline data are available, but inconvenient to use directly. I made an abstraction, [playhead-tick], that generates whole-beat ticks from the raw timeline values, detailed in the second half here:
... using objects in https://github.com/jamshark70/hjh-abs
This way, each individual patch can know what beat it is on the timeline, and this would be the same across all of them.
When you say "'complex' timer," of course there's no way for a reader here to know what you mean. But it's possible to synthesize any timing you like from equally spaced ticks. I also have a [tick-scheduler] object in my abstraction pack where you can reschedule messages at any intervals you like (= synthesizing timing).
[playhead-tick] was originally designed as a companion to the scheduler, but later I felt that a clock-multiplier approach is easier for most cases and more idiomatic to Pd -- so the video demonstrates only the clock multiplier. (To be honest, incremental rescheduling based on time deltas turned out to be a bit clumsy in Pd -- it can be made to work but never felt to me like a natural idiom. There's an example in the [tick-scheduler] help patch.)
hjh
-
Wow! Thanks for your detailed explanation. I'll take some time to analyze it and trying to apply to my project. Great PD community!
-
you can learn about things, play around, make single sounds, make songs, make performance patches or build actual software "products".
the proposed "one song one patch" use case is quite common.