When using [line~] that's more or less it. [vline~] allows you to add a delay time to the message so you can schedule several ramps at once. To truly harness this, though, it would help to understand lists in Pd. Check out this tutorial on using lists and [vline~] to make an adsr envelope generator, if you're interested:

http://www.footils.org/cms/weblog/2009/mar/21/adsr-envelopes-pd/

You don't need [t3_bpe] or [t3_line~] anymore. That article and those externals were written before [vline~], which now comes with Pd-vanilla and is much more widely used. You should definitely use [vline~] for percussion sounds whenever possible because the timing is more accurate and you can get finer control of attacks.

A couple of envelope tips:

1. Squaring the output of the envelope will give you an exponential decay, which is much more natural sounding.

[vline~]
| \
[*~ ]

2. Squaring the output also gives you an exponential attack, which may not be so natural sounding and actually kind of sucks for percussion. However, I've been using a nice little trick to get better attacks from this. You can use a low-pass filter to smooth out the envelope (or any signal). By giving the envelope an instant attack and sending it through a [lop~], you can use the cut-off frequency to define you a short, quick attack that has a more natural rise while keeping the exponential decay:

[1 0, 0 100 0( <--instantly jump to one, go back to zero after 100 ms
|
[vline~]
| \
[*~]
|
[lop~ 100]

As far as the mechanics of the envelopes go, I can't really help you with pd stuff. I've only been working with it for a week or two and so far have only dealt with oscillator configuration.
So yeah, I still don't know much about the pd envelopes.

I can post a couple kicks though.
The first is actually based off of a sample. The sound mostly comes from a high-resonance bandpass filter sweeping down quickly
The second was built with two sine-like oscillators with different filter set-ups. The one has a more gradual attack on the filter and pitch envelopes to give it more of a whoosh.

http://www.pdpatchrepo.info/hurleur/twokicks.wav

Thanks

Hum.. Actually, I'm not successful with envelopes. I'm trying to make it correctly. I have a lot of work to do on this machine (years) !

About envelopes ;

Should I use [t3_bpe] objects for faster envelopes ? (When I'll master envelope principles. Don't give me solutions, I want to discover myself..)

I found it here : http://footils.org/tut/pddrums/pddrums.html

About sound ;

Could I listen to your kick ? (The fattest one ^^)

The parent isn't quite complete, but here is what's there so far. Only the first partial is hooked up, but from everything I've been tinkering it is not sounding out.

I'm using stripnote to remove the note-off events; the note value routes into the abstraction and is multiplied both translated into a frequency and multiplied with a modal value to give the partial needed; the velocity data is turned into a bang which will eventually bang on all the envelope values on the right.

What I do find funny is that that using env~ attached to a number object I see envelopes generating after each of the abstractions, even after att-

Damnit, now it's working. I did modify the original file I uploaded here(add_ab) in one way; I took the 'unpack f f f' out of the line and connected the mtof directly to the new partial inlet.

I started with a polysynth parent attempt, but scaled back to a mono until i had a working framework for one voice. Which I have now.

On a seperate note, is using expr the best way to generate log based envelope curves?

http://www.pdpatchrepo.info/hurleur/AddMonoSynth.pd

transcomp~ uses transdetect~ to shape the initial attack and release of a signal.

Requires IEM's FIR~, fexpr~ and dbtorms~ which are provided in PD-Extended.
To work properly the transdetect folder should be added to PD's path.

Start by opening help-transcomp~.pd

01 Implementation:

transdetect~ works by using two pairs of envelope followers. The first pair
subtracts an envelope follower with a slow attack from an accurate follower,
the result of which is a signal containing the initial attack. For the initial
release, the second pair subtracts an accurate envelope follower from one with
a slow release.

An envelope follower measures the mean square power of a signal over time
(see 3.audio.examples/H06.envelope.follower.pd for details on implementing an
envelope follower). To do this we must use a low pass filter at a very low
frequency. In order to achieve an accurate follower a linear phase FIR filter
was used (using IEM's FIR~ external). Unfortunately this introduces a phase
delay.

In order to facilitate the use of different envelope follower implementations,
transdetect~ requires a filter type as a creation argument implemented in
followernameTransDetectEF~.pd. 4 linear phase fir implementations are provided:
181, 251, 451 and 501 taps filters. The 501 taps filter provides the most
accurate filter but with a phase delay of 5.668 ms at 44.1kHz (raise the
sampling rate to lower the phase delay). They were all generating using
http://www.dsptutor.freeuk.com/FIRFilterDesign/FIRFiltDes102.html with a
cutoff frequency between 5 and 10 Hz.

A compromise between accuracy and phase delay might be achieved by using
minimum phase FIR filters. A 5th implementation using PD's native lop~ object
is also provided under the designation iir (FIR~ not required).

Along with different possible envelope follower implementation transdetect~
also requires an attack and hold type implemented in
attacknameTransDetectAttackShape~.pd and holdnameTransDetectHoldShape~.pd
respectively. These implementations dictate the kind of attack and release
curves used on the envelope followers (linear, slow[er|est] and fast[er|est]).
All implementations provided use fexpr~. A more efficient external could be
made to take fexpr~ place.

02 Use

In help-transcomp~.pd patch enable start and pay attention to the snap in the
hit. Disable the green toggle button to disable the compression make the snap
go away. Check out the tables on the left to see the results of the transient
compression.

transcomp~ is useful when used with recorded drums to maximize or minimize
its transient (to make it punchier or to make snare drums less clappy).

transcomp~ uses transdetect~. By itself transdetect~ can be used to synthesis
hits from a recording. For example, take a bass drum recording and use the
signals generated by transdetect~ to shape the frequency and envelope of a
synthesized kick drum.

Would love to have some feedback and some help in turning the linear phase filters into minimum phase filters.

http://www.pdpatchrepo.info/hurleur/transdetect.rar

Hi there..

I made an envelope but I can't figure out what I did wrong. Please see the .pd file for more information.

Thanks!

http://www.pdpatchrepo.info/hurleur/Envelope.pd

Thanks to both of you. I'll eventually try both.

Hardoff, the grains are never triggered in my patch - I have them being driven by a phasor whose phase is changed for each granplay~ and sent to a tabread4~, whose output is enveloped by the positive part of a cos~. Do you think it might make sense to just quietly change the offset during the part of the cycle when the envelope is at zero? That way, would I avoid having to actually trigger things and get around the delay timing inaccuracies I've been reading about? Or would I get a bunch of clicking because a delay would not allow me to change the offset at the precise moment when the envelope is at 0?

Also, is there a better envelope to use than a cos~? I was thinking maybe something like -(x^6)+1 would be closer to an "equal power" fade - is that correct?

Thanks so so much.

Well for now I'm concerned about getting an authentic sound without worrying too much about emulating the specific operation of the hardware. I also want to add a few extras that the original didn't have, like vibrato, sweeping of the triangle channel, and maybe some other small odds and ends.

The pulse channel sound is simple to emulate, especially if you aren't concerned about timing their length & envelope data against other components, like the frame counter or interrupt lines. The triangle is a bit trickier to get authentic.

The noise channel is particularly difficult to emulate, at least for the inexperienced like me. The NES noise sound in itself is easy to reproduce as a sample using 4bit level quantized noise. The 2A03 actually uses a long shift register and a XOR gate to generate a new pseudo-random bitstream for noise samples. Rather than use my very own enveloping like I did for pulse and triangle channels, I will have to reproduce the native specs of the counters/timers and decay envelope modes, especially to get the looped-decay noise channel mode to sound authentic.

So I guess I will be using some of the same dataflow and control logic that the hardware uses, but I want to cut as many corners as I can right now, especially where I can easily provide userdata through the GUI instead of poking 6502 assembly. Then I can use my own, simpler methods for programmable manipulation of all of the inputs, but ideally get the same-sounding output as I would programming the actual hardware.

Right now I'm going through this document to try and get a full picture of the hardware:
http://nesdev.parodius.com/NESSOUND.txt

I believe that has everything needed to directly emulate the channels, I just gotta keep studying the hell out of it until I can determine all of the specifics on timing, mode switching, sample sizes and such.

The zenpho patch looks similar to what I want to use eventually for making real music, I'll probably refer to that a few times. I see he uses a completely diferent PWM routine than I do. Once I get the NES channels sounding properly, I plan to keep adding voices from other old sound chips I enjoy along with more extras and use it as my main synth.

Thanks alot for that headlessbarbie link. Really amazing stuff. I've had thoughts about later on trying to emulate the 2A03 hardware directly, so that I possibly could put pd on a board with a fast CPU (maybe a SuperH) that would be small enough to fit in a NES cart. Then I could use pd as just an interpreter between the user and the real live sound hardware.

for saving sample cuts, just make a few arrays, and then use a tabwrite~ object to put your cuts in those arrays. i do this realtime, with no problems.

you can then read back from those arrays, using tabplay~, if you just want the same pitch/speed, or tabread4~ if you want to alter the speed.

as for "shaping" , i'm not really sure what you mean here, but i'm guessing you want to use an envelope (stored in an array) to control a filter or the pitch or speed of playback. or something like that. there are other data structures you can use, bu i have found just freedrawing an envelope into an array is pretty simple.