• weightless

    @LarsXI In the 3-op synth patch you mentioned there is an option the synch the phasors when you hit a new note, I don't know if that helps with what you are saying.

    It's good to know that it's a little cheaper, anything helps as by the time you add polyphony things add up pretty quickly. I think that making a full-blown polyphonic 6-op synth with this method is pretty unrealistic, I think it's interesting to experiment with less operators and different waveforms. I did modify that 3-op synth with added waveforms like the TX81z, but then got carried away and added CZ-style oscillators too and that messed up the patch and I never had time to fix it.

    I look forward to your 2-op patch, those camomile plugins you posted sound pretty sweet.

    posted in technical issues read more
  • weightless

    (I'll write here just to keep all the fm discussion in one place).

    @LarsXI this is a great trick I hadn't thought of, sounds identical to the [tabsend~] method to me. I'm curious to experiment with it and see if it's cheaper on the cpu. Delay lines can get down to 1 sample delay without [block~] with the order of execution (G05.execution.order.pd). This won't work for feedback though.

    posted in technical issues read more
  • weightless

    @djpersonalspace Yes, you are right FM8 used phase modulation. And yes, I'm pretty sure feedback is only possible in PM and not FM, either way it's definitely the way to go if you are using multiple operators and non-fixed algorithms.

    You are welcome, I hope you can get something out of this patch. I think this way of doing phase modulation is the best sounding I've heard, but it's very cpu heavy.

    posted in abstract~ read more
  • weightless

    @djpersonalspace Thanks for sharing the patch you're working on. I should point out that your patch uses "real" FM, which means that you directly modulate the frequency of an osc~, whereas my patch (like most implementations of FM) uses what is called "phase modulation", where you modulate the phase lookup of a sine wave instead. This is a key difference to understand if you are trying to implement multi-operator FM.
    For the basics on this, have a look at help > browser > pure data > 3.audio.examples > E08.phase.mod.pd

    This is what my mod matrix is doing in the patch, there is one table which holds the phase of each operator, and every time some other operator is sent to modulate it by some amount (aka the modulation index), the output of this modulator is added to the table along with all the others that are set to modulate it. I think that once you understand the difference between FM and PM this becomes clearer.

    You could do all this in a simpler way with s~, r~, throw~ and catch~. The reason I'm doing all this madness with tables here is because I wanted to have feedback as well for each operator, and in order to do so the phases need to be updated sample by sample, whereas s~ and r~ objects only work in chunks of 64 samples. That doesn't sound right when you try it.

    posted in abstract~ read more
  • weightless

    @djpersonalspace Hi, the main mod matrix is inside [pd DSP], then click on the [clone] object, [PMops $1] and then [tables $0]. This is an abstraction file (tables.pd) that receives the phases for all operators, so they can be updated with a 1 sample precision. This abstraction is inside the [clone] object, so of course each voice of the synth uses a different instance of the tables abstraction.

    I settled on 4 voices and 3 operators because anything more than that seems too heavy on my cpu, but if you follow the same principle you can keep adding tabsends, tabreceives and tables for the new operators to the abstraction. If you need more voices, just change the number 4 in the [clone] and [poly] objects inside [pd DSP].

    Hope this helps, it's been a while since I made this and I remember that this method of doing the modulation matrix wasn't intuitive to me either at the time.

    posted in abstract~ read more
  • weightless

    @kevinschlei I don't think there is but Purr Data has those and is arguably nicer.
    https://github.com/agraef/purr-data/releases

    posted in extra~ read more
  • weightless

    @t3zeu5 Here are two abstractions I made some time ago for that purpose (plus other useful abstractions used in the help files). They suited my needs but can be easily adapted to yours I think. Take a look at f2scale-help.pd and subset-help.pd. Hope this helps.
    quantize-abs.zip

    posted in technical issues read more
  • weightless

    @rpgidem check out [bonk~].

    posted in technical issues read more
  • weightless

    @Fauveboy this is my version of the vanilla pipelist using [text]:
    vpipelist.zip

    posted in technical issues read more
  • weightless

    @Fauveboy
    for [prepend], you can use [list prepend] followed by [list trim].
    for [unpackOSC], I think [oscparse] should do the same.
    for [pipelist], this is trickier but I have a feeling it could be done with a combination of [text] objects. You can have a look at [list-fifo] as well (a vanilla abstraction from the list-abs library), but I don't think it does the same thing as [pipelist].

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!