Hello,
I'm working on a pd synth based on the phase modulation flavour of FM and I'd like to implement the 8 waveforms used in the early Yamaha 4-op synths like the TX81z.

I found a picture of how they look like and, as far as my understanding goes, in those synths they were created by altering the readout of a sine table. I'd like to keep it that way so the table resolution could be changed etc.

These are the ones I've got so far, I'm not sure if my approach is correct but this way all the phase modulation (from carriers or itself in the case of feedback) would happen before the [expr~]. (see the pd fm subpatch)

tx_waveforms.zip

If anyone has some insight on how to obtain the others it would be much appreciated! I've tried to get clues from the casio cz oscillator patch posted in this forum, since this looks to me like a case of phase distortion, but I couldn't understand much of what was going on there.

Thanks for the help.

@weightless

I don't have any answers for you to get those arcsin-looking waveforms... but I have also been curious about how to use tables instead of the phasor-cos~ pairing... since the latter generally has nicer sounding modulation
cos_vs_sintable.pd

@katz

When you do phase modulation with a table, you need to [wrap~] the phase before [tabread4~] to make sure it's in the 0..1 range. If you do that in your patch, it sounds exactly the same as [cos~].

cos_vs_sintable_wrap~.pd

@weightless

Ah that was right there in your first example. Nevertheless, amazing - thanks.

@weightless

I cheated to get some pre-made waveforms with this one (waveforms 2,4,6,8 may not be accurate), and I am wondering if there is an advantage to using the audio math instead, because this one is certaintly lighter. I added a tri-wave at 9 too.

tx-wavs.pd

@katz

Thanks!
Indeed, using separate tables is the way to go here since the audio math is way too heavy for my computer for a patch with 4 voices and 3 operators per voice. Maybe there was an advantage on the 80's hardware, but definitely not here.

I have no way of knowing whether they are accurate either since all I've got is that picture, but I'm not going for an historic recreation of any of those synths. I just wanted to have something else other than sine, and those looked like a good place to start.

In fact, I've tried using those casio cz oscillators too (https://forum.pdpatchrepo.info/topic/5992/casio-cz-oscillators) in this context and they sound interesting. Here you basically have your waveforms modulating the phase of the cz waveforms before the phase distortion happens.

tx-wavs_cz-wavs.pd

Thanks for your help, I hope to be able to post the whole thing soon.

on a sidenote: on vanilla 0.47.1 I can't create [asin], but have got it to work with [expr asin($f1)], not sure why.

@weightless

I thought it might be nice to group all the waveforms to be read from a single tabread4~ for each operator, and here is the result. The trade-off is that the casio waveforms cannot be modulated at the 2nd input since they are now calculated statically (you can change them live but since the tables are being redrawn, its unusable that way). The feedback is in here too and a comparison w/ the original cos~ style.
txcz-wavs.pd

@katz

thanks for your input, and the table cz waveforms are definitely a lot cheaper this way too. Regarding the live 2nd input modulation, maybe that could be done by using two tables (read the first table, then when a change occurs write to a second table and then switch to that once it's been computed or at the next phasor~ cycle or something), or perhaps pre-compute say 5 resonance steps for each cz waveform (keeping in mind that some combinations of waveforms/resonance might be redundant as they are too similar to the tx ones).

Maybe it's best to just use tables in case we want to add other waveforms later on.

I haven't got time to look at it properly now but I can see I'm missing [arraycopy] on vanilla, not sure what it does.

Thanks.

@weightless

I tried your idea with the alternating tables only, but even the "set" messages will cause some clicks, so here is one with tabread4~ & volume alternating that works. The extra cost is one tabread4~ & two sets of line~s and [*~]s but with effective [switch~]ing you could take away the extra tabread4~.

I also experimented with different array sizes (see the switcher at the top-right), and certain waveforms are affected quite a bit while others remain the same, so if someone wants to go this route, the whole setup could be fine-tuned per waveform. In this patch the [*~] before the tabread4~s is changed by a 20ms line~, but if you wanted to change the waveform per voice in a polyphonic setup, before the volume envelope kicked in, and each waveform had a specific table size, this would have to be done immediately with a way to avoid the click.
txcz-wavs2.pd

@katz

I'm not going to be able to see your patch for a few days, but one thing that is interesting on my CZ1 is that each oscillator can play two waveforms one after the other in tandem, as it were. I think this would be very interesting to try in a FM context (perhaps even with the ability to chose the TX waveforms as "waveform1" and "waveform2"), maybe even more interesting than being able to change the resonance of the CZ waveforms in real time since a similar effect is achieved by increasing the modulation index. Again, I haven't tried your patch so perhaps you did find an effective way to do it, and that would be great.

I'm a bit surprised that changing table resolution has much of an effect on the sound, unless you use [tabread~] instead of [tabread4~] as I thought the interpolation would make everything smooth regardless, but I could be wrong. Anyway the Dx7 used linear interpolation (aka [tabread~]) for the readout so that can create interesting artefacts and is certainly something I wanted to experiment with as well.

@weightless

Ok here is a final one that simulates the cz waveforms in series by writing half of the array in the first chosen waveform and the other half by the second. If both waveforms are the same, the second phase slider won't do anything.
txcz-wavs3.pd

As far as the array size I am not sure, but I believe at the really low resolutions the actual shape of the waveform is simply altered.