Simone

I have built a synth that includes the tri~ object. I

have noticed some strange behavior which illustrated

by the patch below. In my synth I am using a line~

object before an mtof~ object. I use the line~ object

to slide between pitches sent to the various

oscillators including tri~. When the slide time is 0

the signal from tri~ seems to phase in and out. It is

most noticeable when the signal passes through an

overdrive~ object which is also part of my synth. 

Anyone know why this is happening and how I can avoid

I have built a synth that includes the tri~ object.  I
have noticed some strange behavior which illustrated
by the patch below.  In my synth I am using a line~
object before an mtof~ object.  I use the line~ object
to slide between pitches sent to the various
oscillators including tri~.  When the slide time is 0
the signal from tri~ seems to phase in and out.  It is
most noticeable when the signal passes through an
overdrive~ object which is also part of my synth. 
Anyone know why this is happening and how I can avoid
it?

tri-issues

I want to thank you very very much. I have had several reports of

problems with tri~, and I was able to reproduce them, but I was never

able to figure out just what the heck was wrong with the object. I

wasted many hours exploring all sorts of complicated solutions for

what I thought was the problem, but I was never able to fix it. But

for some reason tonight, after looking at your VERY CLEAR EXAMPLE

PATCH, I opened up the code and the bug was fixed in less than a

A fixed version of tri~ will be in the next Max/MSP update. I am

currently away from my office and don't have an OS X computer handy,

but I'll be home tomorrow and will make the fixed externals available

I want to thank you very very much.  I have had several reports of
problems with tri~, and I was able to reproduce them, but I was never
able to figure out just what the heck was wrong with the object.  I
wasted many hours exploring all sorts of complicated solutions for
what I thought was the problem, but I was never able to fix it.  But
for some reason tonight, after looking at your VERY CLEAR EXAMPLE
PATCH, I opened up the code and the bug was fixed in less than a
minute.  Wow that feels good!

A fixed version of tri~ will be in the next Max/MSP update.  I am
currently away from my office and don't have an OS X computer handy,
but I'll be home tomorrow and will make the fixed externals available
tomorrow night.

just wondering when the fixed version of tri~ might be

just wondering when the fixed version of tri~ might be
available...

Another problem with tri~ is that when you play a bit with the duty 

cycle parameter (expecially if you go a few times from 0 to 1) the 

signal become eventually a stream of "inf"s.

Another problem with tri~ is that when you play a bit with the duty 
cycle parameter (expecially if you go a few times from 0 to 1) the 
signal become eventually a stream of "inf"s.

-- 
HomePage: http://www.giri.it
Computer Music Italian Forum http://www.virtual-sound.com


> just wondering when the fixed version of tri~ might be

It's available now from the incremental downloads page:

https://cycling74.com/twiki/bin/view/IncrementalDownloads

> just wondering when the fixed version of tri~ might be
> available...

Sorry, but I'm not able to reproduce your bug with the latest version of tri~.

unfortunately I still can reproduce it, expecially when I change the 

NB I only have one version of tri~ in my computer. The creation date 

unfortunately I still can reproduce it, expecially when I change the 
duty cycle very fast a few times...

NB I only have one version of tri~ in my computer. The creation date 
is Feb 14 2006

I did some digging, however, and I'm finding that the infs don't seem 

to be related to just changing the duty cycle, but rather, subjecting 

the duty cycle parameter to "unnecessary" roughness. I can use a 

dc-offset [cycle~ 10.] to modulate the duty cycle all day long, and 

there's no issue, but if I run it through [~* 100] -> [clip 0. 1.]... 

the min/max values of the resulting waveform from tri~ are... strange. 

OSX 10.3.9
MaxMSP 4.5.6
Newst version of tri~
powerbook g4 1.5 Ghz

  I did some digging, however, and I'm finding that the infs don't seem 
to be related to just changing the duty cycle, but rather, subjecting 
the duty cycle parameter to "unnecessary" roughness. I can use a 
dc-offset [cycle~ 10.] to modulate the duty cycle all day long, and 
there's no issue, but if I run it through [~* 100]  -> [clip 0. 1.]... 
the min/max values of the resulting waveform from tri~ are... strange. 
FWIW.

I believe we are moving closer to a well-behaved object. Please

download and install the new version at the incremental updates page

Do not hesitate to let me know about any bugginess that persists!

I believe we are moving closer to a well-behaved object.  Please
download and install the new version at the incremental updates page
at

Dutifully yours,
Ben "tri~ceratops rex" Nevile


Spotted some new problems with the tri~ object, now the year 2023. It is being used inside a poly~ object. It is an FM synthesiser. The tri~ is one of the oscillators that modulates the frequency. There are 16 voices. When the oscillator frequency is changed by a lot in response to a different midi pitch, it takes 16 long plays before the heard sound stabilises, 16 the same number of voices. If the tri~ is replaced with a cycle~ object (playing the default sine wave), this strange behaviour is no longer present. The tri~ has the behaviour of some built in portamento that I never programmed in and besides, I could not see an option in the tri~ object to set a ramp time for frequency changes.

the meaning of bandlimited FM operators is not void, but you should also not overrate it.

and i believe a ramp time / duty cycle of 0. ms would not be possible for generators of that type tri~ belongs to. 

if you want that, you needed to use the additive synthesis approach to build your own bandlimited oscillator (which is easy to make, but eats up quite some CPU at higher orders)

before i would use tri~ (where nobody really knows what its duty cycle settings actually does) i would rather user 

otoh, if you make an additive tri wave you are getting rid of the aliasing issue by 100%, and it should be pretty fine for FM to do a very lower such as... hm, well, for tri... maybe 13 or 15?

and i believe a ramp time / duty cycle of 0. ms would not be possible for generators of that type tri~ belongs to. 

if you want that, you needed to use the additive synthesis approach to build your own bandlimited oscillator (which is easy to make, but eats up quite some CPU at higher orders)

before i would use tri~ (where nobody really knows what its duty cycle settings actually does) i would rather user triangle~ followed by 8 copies of slide~ 4 4  (roughly -24db at nyquist?)

otoh, if you make an additive tri wave you are getting rid of the aliasing issue  by 100%, and it should be pretty fine for FM to do a very lower such as... hm, well, for tri... maybe 13 or 15?


Thanks Roman for your reply. In the mean time I have been able to repeat the problem of tri~ inside a poly~ that drives fm synthesis using a very simple patch. The poly code needs to at least run once for any one voice to function properly. I was hoping that 2d.wave~ would come to the rescue, but feeding it a recorded tri~ signal just gives a whole lot of aliasing problems at higher frequencies. So there must be some interesting code inside tri~ to do this frequency band limiting.

As for duty cycle, I have not altered this from the default for the tri~ object. Will have a look into the triangle~ and slide~ object combination you talk about.

The other solution is to include in the startup code, something to fire off a midi note for each voice, to wake up the tri~ inside poly~ so it starts behaving properly. Hm a bit like turning on your analogue synth with tubes, you have to let it warm up before you can you use it — oh dear. A shame the development team have not sorted out this tri~ problem. Or maybe it is a problem with poly~ that it does not instantiate properly the code you put into it.

Thanks Roman for your reply. In the mean time I have been able to repeat the problem of tri~ inside a poly~ that drives fm synthesis using a very simple patch. The poly code needs to at least run once for any one voice to function properly. I was hoping that 2d.wave~ would come to the rescue,  but feeding it a recorded tri~ signal just gives a whole lot of aliasing problems at higher frequencies. So there must be some interesting code inside tri~ to do this frequency band limiting.

The other solution is to include in the startup code, something to fire off a midi note for each voice, to wake up the tri~ inside poly~ so it starts behaving properly. Hm a bit like turning on your analogue synth with tubes, you have to let it warm up before you can you use it — oh dear. A shame the development team have not sorted out this tri~ problem. Or maybe it is a problem with poly~ that it does not instantiate properly the code you put into it.


The related article https://cycling74.com/articles/advanced-max-an-inquiry-into-maxs-slide-objects

from Timothy Place, explains the slide~ object and how it can be used to act as a filter on the triangle~ object data that Roman talked about. Next step for me is to see if this solves the tri~ problem in the poly~ object giving bad output for the first plays of each voice in the fm synthesis -- fingers crossed.

Woo Hoo. Problem solved no more bad numbers coming out of the tri~ object from within the poly~ since it has been replaced with a gen~ patcher using the signal chain of phasor -> triangle -> slide plus suitable scaling and offsetting of the triangle output (ha ha, gen~ uses a different range to none gen triangle~ output.

The related article https://cycling74.com/articles/advanced-max-an-inquiry-into-maxs-slide-objects
from Timothy Place, explains the slide~ object and how it can be used to act as a filter on the triangle~ object data that Roman talked about. Next step for me is to see if this solves the tri~ problem in the poly~ object giving bad output for the first plays of each voice in the fm synthesis -- fingers crossed.

PS.\
Woo Hoo. Problem solved no more bad numbers coming out of the tri~ object from within the poly~ since it has been replaced with a gen~ patcher using the signal chain of phasor  -> triangle -> slide   plus suitable scaling and offsetting of the triangle output (ha ha, gen~ uses a different range to none gen triangle~ output.

if you use filters, you do not need tri~ any longer, you can use a simple and cheap triangle waveform.

i have never calculated it through, but it should be a good compromise to take the first upper sideband into account.

for example when i FM two cosines with each other, i substract

 frequency of modulator + frequency of carrie

r from the frequency where i would normally set the bandlimiting filter for a single sinewave (could be samplerate/4)

where in the case of sinewaves or additive harmonics (such as an additive created triangle wave) you will only need a gain change as "filter".

wavetables with harmonics (such as an additively created triangle wave) could undergo the same procedure when using post filters, and you would orientate yourself along the highest partial it contains.

say you make your tri wave out of 5 harmonics; 1, 3, 5, 7, and 9.

if this generator plays at 2000 Hz, the upper harmonics already has 18000Hz, and you would eventually already have made it more quiet for some 5 db - the gain reduction would start at 11khz and at 22khz the partial will no longer be produced.

now you want to FM two of them with each other.

one runs at 400 Hz and the other one at 1000 Hz.

mathematically this is nonsense, but we could now simply assume that this FM will cause (at least) an upper sideband of 1400Hz.

instead of filtering at 11khz you would not filter at 11khz minus 1400Hz.

what does it do? it might contain frequencies up to close under samplerate/2 - no matter its base frequency. that is what bandlimited oscillators are about.

say it has relevant (audible or close under audible) gain at 18kHz.

try all of this using sinewaves first. later you can apply all these methods you found simply to the highest frequency in some other waveform.

for example when i FM two cosines with each other, i substract frequency of modulator + frequency of carrier from the frequency where i would normally set the bandlimiting filter for a single sinewave (could be samplerate/4)

now you want to FM two of them with each other. 

instead of filtering at 11khz you would not filter at 11khz minus 1400Hz.
 
 
so, but now about tri~-. 

what would happen if you FM two of them? 

yes, exactly. at 44kHz samplingrate, 18,000 + 18,000 == -8,000. ouch!


try all of this using sinewaves first. later you can apply all these methods you found simply to the highest frequency in some other waveform.


apropos tri~ problem for the first voice. do you initialize it at 0 Hz or something? tri~ has some issues with properly reproducing low frequencies.

The original code did not limit the input frequencies for tri~ so I put in a clip function to limit between 1 and some high frequency -- this made no difference to the problem. But figured it would be good practice to leave this frequency clipping feature in. Sending tri~ a 0 Hz frequency stops it, just like with cycle~, rect~ and the saw~ objects. I think you are onto something there with the low frequencies. Either way, slide filtered triangle saved the day. Actually the slide has a nice feature of applying separately to the positive and negative gradients of the input audio signal the filter (slide up versus slide down parameter).

As for your question do I initialise it at 0 Hz, no the first frequency is greater than zero Hz. I did revisit the poly~ object, could not spot a method to tell it to "wake up" all the instances. Did try the "mute 0 0" message to poly~ as an initialisation on start up, but this altered nothing, so took it out.

So yes, the Cycling'74 developers have some homework to do to correct the tri~ troubles when used inside poly~ or at the very least document workarounds.

Roman,
The original code did not limit the input frequencies for tri~ so I put in a clip function to limit between 1 and some high frequency -- this made no difference to the problem. But figured it would be good practice to leave this frequency clipping feature in. Sending tri~ a 0 Hz frequency stops it, just like with cycle~, rect~ and the saw~ objects. I think you are onto something there with the low frequencies. Either way, slide filtered triangle saved the day. Actually the slide has a nice feature of applying separately to the positive and negative gradients of the input audio signal the filter (slide up versus slide down parameter).

As for your question do I initialise it at 0 Hz, no the first frequency is greater than zero Hz. I did revisit the poly~ object, could not spot a method to tell it to "wake up" all the instances. Did try the "mute 0 0" message to poly~ as an initialisation on start up, but this altered nothing, so took it out.

So yes, the Cycling'74 developers have some homework to do to correct the tri~ troubles when used inside poly~ or at the very least document workarounds.

tri~ issues