@lovelovevideo As @LucienR says........ the [- ] object only calculates when its left inlet is banged. You got lucky with the left hand chain...... in the order that you connected things..... not so in the right hand chain....... fixed....... but not properly........ needs more work.......speed.pd
You should read this before bed..... stopping when you get to chapter 2.9 (or you will give up!)......... http://puredata.info/docs/manuals/pd/x2.htm
@soulflyer Both "extended" objects in the "extra" folder, so unlikely to have made the leap to vanilla unless you are running 32-bit Pd..
[pan~ ] was an equal power pan.... so you should be able to make one.
I have included the old [splitfilename-help] file and and the windows stuff from extended in hmm.zip
There is also an abstraction......  that represents as far as I went trying to split filenames and lists in vanilla.
@xgr Yes........ with the latency meter...... not if you have an amplifier (mix) patch or program running as that would cause feedback...
You could reduce the click output being sent from the [dac~] with a [*~ 0.01] maybe if the soundcard does not "auto" to "line in"........ or change the soundcard input to "line in" if possible.
Now each generator is separate (voice_gen1, voice_gen2 etc.) and contains it's curves. Change them and save each [voice_genx y z]
The [part_voice] abstractions have the extra argument for which timbre volume curve to follow.
@Ale-H.H. Just back...... but off to bed soon.
This is where, if you had already had your $ variable eureka moment you would find it incredibly easy to implement.
The [part_timbre] already send their output to the sine waves ( [part_voice] ) according to their second and third arguments..... [part_timbre $1 $2 5] sends its output to [s vol-voice..curve.no-part.voice.no] (s vol-$2-$3)... so.......
We need the oscillators to know more things. At the moment they know $1 (their curve) and $2 (the number that they have been given, that gives their multiplier...... which was the same as the timbre curve controlling them)
S now they need to know...
$1...... their curve for notes
$2...... their multiplier
$3...... the timbre curve controlling them
Replace [part_voice] in your folder (before you start your patch) with this........ part_voice.pd
Open your patch and rename for example [part_voice $1 2] to [part_voice $1 2 x] where x is the timbre curve graph ($1 $2 x) controlling it.....
Look inside the new [part_voice]....... all I had to do was change [r vol-$1-$2] to [r vol-$1-$3]........ simple....... the power of abstractions and $ variables.
Once you "get it" you will be able to do all this on your own....... with ease!
@Ale-H.H. To change a graph name you have to select (highlight it) and then right click in the very top left of the graph and select properties...... you then get 2 windows..... one the same as the one you have been seeing and another (hidden below?) where you can change the array name........
Back to bed!
@Ale-H.H. Just quickly..... I am up very early and away tomorrow.....
[pvu~] doesn't matter... it was just for the meters in the mix modules..... I will investigate later.... but it looks in your screenshot as though it is fine.
sends and receives missing?........ probably save each bit and the main patch and then open again.
the abstractions all talk to each other...... so that should solve it.
eg..... voice_out0 means the [voice_out $1] has not got its value for $1...... it needs to be re-opened by the container patch....... that is when it will get its $1 value.
Could not create [udpreceive].......... don't know why? Not at all normal........mrpeach not being found.... should not be anything to do with the patch.
16 0r 32 sine waves should be fine...
Sorry, other stuff will have to wait..
@Ale-H.H. OK....... You are going to have to trust me on this.
This took about an hour to build........ but you can now expand it in seconds.
Abstractions are a powerful tool......... but to build them you need to understand the use of variables ($0 $1 $2......etc.)..
Any abstraction can be copied and pasted......... .So if you want more oscillators within a [voice_gen] just copy/paste a [part_voice] within a [voice_gen] and give it a new number [part_voice $1 "x"]...... Change the pasted one's Name to [part_voice $1 "new voice number").......
It will need a timbre curve as well.... so open the relevant [timbre_gen"y"] and put a new [part_timbre $1 $2 "x"] make a new volume curve $1-$2-x by copy/pasting an existing one...draw a new curve....... and save the main [voice_gen] abstraction once you are happy.
1..... the [timbre_gen"x"] need to be saved individually because they contain the timbre sub-curves. They cannot be used as true abstractions (they must have separate names). If you decide you want a new timbre curve for something then copy and paste an old [timbre_gen"x"], changing its name........ then change the sub-curves and re-save the file.
((this could be done better by writing data out to text files, but I don't have the time now to implement that..... this solution works.......))
2.... If you add more oscillators to a voice then you will end up with some producing ultra-sonics. If you will need to specify some new relationship between the oscillators (other than x2,x3 etc. you can do that by changing the 2nd argument for the oscillators.... i.e. [part_voice $1 0.5] etc.
Don't forget to put the "0.5" in a corresponding [part_timbre] and it's graph....!
I cannot help you to do this without abstractions..... it would be too difficult and too messy.
You are absolutely going to have to understand them for a project like this that is going to become very complex very fast.
See here for some help........ https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
You will not have wasted your time.
The future benefit will be enormous...... as any sudden new idea for your patch can be working 100% just a few minutes later!.
You should probably print this post before you start playing with the patch.
And please do not despair.
You will, probably after a good nights sleep, have a $ eureka moment...... and from then on you will find patching in Pd as easy as Pi....... or is that Pie?.....
New2.zip should be working...... there is nothing clever or unusual.
I might not get time to help for a couple of days. If I get time to integrate a state saving system then I will integrate each [part_timbre] into each [part_voice] and the patching will become even easier.
You have 2 days to get familiar with this way of working...........
@Ale-H.H. I am out tonight..... so no help I'm afraid.
I start to understand.
You can assign curves to what you wish....... so?
Anyway.... the last patch allows you to draw curves for each oscillator controlled by just one iaanix timbre curve.
You just have to decide how each oscillator should respond to that curve to create the timbre.
If you want the first oscillator volume to simply follow the iaanix curve then draw a line in "a" from bottom left to top right.
If you want the last oscillator to do the inverse then draw in "h" a straight line from top left to bottom right.
If you want the second oscillator volume to rise quickly as the iannix curve goes to 0.5 and then fall back to zero as the iannix curve reaches 1 then draw a triangle in "b"
I hope that makes sense.