Hi, I have an array that I'm playing at say 0.017 speed (sending 0.017 to a phasor~ set to cycle through the 65536 -sized array. I'm hoping to find out how to get this pitched down array content to be written to an array - so i can then dump it to a wavefile and use it on another software. How would I go about doing it? so far i have a solution where i have a metronome that runs for $1 (in this case, a calculation of 65536*0.017 = 1114112) and i toggle it "on" and when the array has been written to, i toggle it off. I was attempting to have a delay toggle the toggle off, so the metronome would stop counting around 1114102, but when i tried to loop this through back into the TGL -object, Pure Data crashed fully.
Are there other ways of dumping the exact length of this sample into a wavefile, without using tabwrite~ and metronomes? Could this calculation be done to a writesf~ maybe? i'm hoping to emerge with no repetitions of the array, just a single shot of the array, with the proper length, so it plays from start to finish.
On 2017-01-05 12:57, Esa Ruoho wrote:
i, I have an array that I'm playing at say 0.017 speed (sending 0.017 to a phasor~ set to cycle through the 65536 -sized array. I'm hoping to find out how to get this pitched down array content to be written to an array - so i can then dump it to a wavefile and use it on another software. How would I go about doing it? so far i have a solution where i have a metronome that runs for $1 (in this case, a calculation of 65536*0.017 = 1114112) and i toggle it "on" and when the array has been written to, i toggle it off. I was attempting to have a delay toggle the toggle off, so the metronome would stop counting around 1114102, but when i tried to loop this through back into the TGL -object, Pure Data crashed fully.
Pd should not crash. if you experience a crash, you should post a (minimal) patch that exposes the problem, so it can be fixed.
anyhow, [phasor~] and [metro] both repeat, so they seem to be the wrong choices for a one-shot operation, instead of [line~] and [delay].
also i don't understand why you would want to dump the array into another array in order to record it. sending the audio to a [writesf~] directly should be enough.
[bang( | [array size foo] | [t f f b] | | | | | [samplerate~] | [/ ] | [* 1000] | [/ 0.01666666] | | [pack] | [t l b l] | | [$2( [0, $1 $2( [start( [delay] | | [stop( [line~] | +-------+ | |/ [tabread4~ foo] [t a] | / | +------------------+ |/ [writesf~]
fmsdrt IOhannes
On 5 January 2017 at 17:30, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-01-05 12:57, Esa Ruoho wrote:
i, I have an array that I'm playing at say 0.017 speed (sending 0.017 to
a
phasor~ set to cycle through the 65536 -sized array. I'm hoping to find
out
how to get this pitched down array content to be written to an array -
so i
can then dump it to a wavefile and use it on another software. How would
I
go about doing it? so far i have a solution where i have a metronome that runs for $1 (in this case, a calculation of 65536*0.017 = 1114112) and i toggle it "on" and when the array has been written to, i toggle it off. I was attempting to have a delay toggle the toggle off, so the metronome would stop counting around 1114102, but when i tried to loop this through back into the TGL -object, Pure Data crashed fully.
Pd should not crash. if you experience a crash, you should post a (minimal) patch that exposes the problem, so it can be fixed.
well, it became unresponsive. but this i think was because i had a toggle going into a bang, which was sending to a delay, which was trying to untoggle the toggle, which would then send out a bang. so it was my fault really, endless feedback loops causing unresponsiveness and then me not being able to remove a specific segment of it to stop it from feedbacking/being unresponsive. so no point really trying to fix, right? :)
anyhow, [phasor~] and [metro] both repeat, so they seem to be the wrong choices for a one-shot operation, instead of [line~] and [delay].
also i don't understand why you would want to dump the array into another array in order to record it. sending the audio to a [writesf~] directly should be enough.
Thing is, the array (let's call it plom) is played at like 0.0017 speed or more, so to capture what "plom" sounds like when pitched down, i thought i'd have to write it into an array, and save that array safely. maybe i've misunderstood, but i was able to then capture it into an array and write that array. i was just hoping to do it in a snappier way rather than having to have a metro toggled on, until it felt like the array was full, and then stop the metronome, and then manually tap on save-sample.
so far i'm quite happy with how the script goes, it's very simplistic, just two oscillators, a delay, a method of sampling the oscillators+delay result into an array (plom), then a midicontroller knob to control the playback of the array (plom) between -2 and 2. now i'm just trying to get the happy accidents (plom pitched down) into a randomly named filename (or maybe a date/time named filename) so that i can retain them, instead of losing them everytime pure data is booted.
[bang( | [array size foo] | [t f f b] | | | | | [samplerate~] | [/ ] | [* 1000] | [/ 0.01666666] | | [pack] | [t l b l] | | [$2( [0, $1 $2( [start( [delay] | | [stop( [line~] | +-------+ | |/ [tabread4~ foo] [t a] | / | +------------------+ |/ [writesf~]
after numerous mistakes, i was able to (i think) get this to work somehow. i'm not sure if foo = plom, but i put tabread4~ and array size as plom (as that's the original material). i am able to now feed the phasor~ playback speed into the [/ 0.016666] -2nd port, and if i tap on start, and wait a while and tap on stop, i get a type of sound. it's not in the same pitch as what i'm hearing, so what i hear isn't quite what i get, but it's definitely a step in the right direction. i took a screenshot of what i ended up with, if that helps. http://imgur.com/a/Gu6bz
i'm kind of halfway there, thanks to you! all i gotta do is get it to actually be at the same pitch and work, and figure out if i should just keep with 0.01666666 that you suggested, or have that be changed by the playback speed (that i'm using to feed to phasor~..
and the 2nd step is to get the date-time writing to the filename and somehow stash the long-ish path somewhere. phew. i never thought i'd get this far!
On 01/05/2017 10:26 PM, Esa Ruoho wrote:
after numerous mistakes, i was able to (i think) get this to work somehow. i'm not sure if foo = plom, but i put tabread4~ and array size as plom (as
yes. i think my patch has only two magic values:
- "foo" is the table name
- "0.0166666666" is the playback speed.
that's the original material). i am able to now feed the phasor~ playback speed into the [/ 0.016666] -2nd port, and if i tap on start, and wait a while and tap on stop, i get a type of sound.
the idea is to just click on "bang" (at the top of my patch), and it will simulatenously start playback and recording and then stop recording once the table has been played back.
it's not in the same pitch as what i'm hearing, so what i hear isn't quite what i get, but it's
this is most likely because the samplerate settings of your patch, your soundcard and/or the soundfile do not match.
definitely a step in the right direction. i took a screenshot of what i ended up with, if that helps. http://imgur.com/a/Gu6bz
i would advise you to learn to use abstractions.
fgmdsa IOhannes
On 6 January 2017 at 00:49, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 01/05/2017 10:26 PM, Esa Ruoho wrote:
after numerous mistakes, i was able to (i think) get this to work
somehow.
i'm not sure if foo = plom, but i put tabread4~ and array size as plom
(as yes. i think my patch has only two magic values:
- "foo" is the table name
- "0.0166666666" is the playback speed.
I will switch the 0.0166666 = $1 and try and feed it from the calculations (i.e. the number that the pd-script already provides elsewhere).
that's the original material). i am able to now feed the phasor~ playback
speed into the [/ 0.016666] -2nd port, and if i tap on start, and wait a while and tap on stop, i get a type of sound.
the idea is to just click on "bang" (at the top of my patch), and it will simulatenously start playback and recording and then stop recording once the table has been played back.
weirdly enough, after trying to replicate it ( see screenshto http://imgur.com/a/oD2C5 ) it still does not seem to work. what am i missing between transcribing pd-mailinglist-info to pd-vanilla? is there some glaring mistake somewhere? :)
it's not in the same pitch as what i'm hearing, so what i hear isn't quite what i get, but it's
this is most likely because the samplerate settings of your patch, your soundcard and/or the soundfile do not match.
I'll have to see what samplerate soundflower is operating at and match somehow.
definitely a step in the right direction. i took a screenshot of what i
ended up with, if that helps. http://imgur.com/a/Gu6bz
i would advise you to learn to use abstractions.
what are they? i've thus far worked on a single screen instead of hatching things inside [pd sampleplayer], just so that when i start recycling pitched-array to replace osc~, things don't go all complex with multiple inlets and outlets. i guess i could try and figure out how to use abstractions to create those time-date filenames, but am trying to tackle the pitched-down-sample-diskwriting first and then start attacking the "retain long-path" + "generated filename" = pack = feed to writesf~ open-dialog..
On 01/06/2017 01:22 PM, Esa Ruoho wrote:
weirdly enough, after trying to replicate it ( see screenshto http://imgur.com/a/oD2C5 ) it still does not seem to work. what am i missing between transcribing pd-mailinglist-info to pd-vanilla? is there some glaring mistake somewhere? :)
your transcription looks good. it might help to know what it is that makes you think that it "does not seem to work".
gmdasr IOhannes
On 7 January 2017 at 00:07, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 01/06/2017 01:22 PM, Esa Ruoho wrote:
weirdly enough, after trying to replicate it ( see screenshto http://imgur.com/a/oD2C5 ) it still does not seem to work. what am i missing between transcribing pd-mailinglist-info to pd-vanilla? is there some glaring mistake somewhere? :)
your transcription looks good. it might help to know what it is that makes you think that it "does not seem to work".
I had to rejig it a little bit, and combine it with the filename-naming system, and then i got it to work. unfortunately, the filenaming system is quite random now, since i haven't figured out how to create a timestamp using pd-vanilla. here is an image of what i have right now.
bugs i've identified are 1- if you go below 0, the whole system stops working. i guess the solution would be to reverse the line code to [$1, 0, $2( and use a moses that detects when it is at negative space and when it is at positive space. not sure if i can make it work though. 2- if i try to render at 0.015748 speed (anything below 0.04), the rendering never happens - it's like it is somehow too slow for rendering?
On 01/06/2017 01:22 PM, Esa Ruoho wrote:
i would advise you to learn to use abstractions.
what are they?
they are Pd's answer to structured programming. (i'm really talking about re-usable, file-based abstractions (patches saved to disk, and used as objects), rather than [pd] subpatches, which are only a means to hide the guts of your patch)
fgmadsr IOhannes
-
Esa Ruoho -
IOhannes m zmoelnig -
IOhannes m zmölnig