@porres said:

@gentleclockdivider said:

The uzi spits outs values 1-64

you probably want 0-63, and help file of [uzi] tells you how to set from 0 with the 2nd argument, The trigger part is bad, you should have just first sent it to the right then to the left, but I just simplified the whole thing by just using [expr] to do it all... I am also using [loop] from ELSE which I think has a better desing and works best

Thanks
I dont know why you say the trigger part is bad .
Sure I could have send it first to the right inlet of write and then left (which I have don previously ) , but using a TBF for the index I am sure that value at the left input ( float module ) will be triggered by tbf

Can someone help me out here , I've done this a million times but this is really getting on me
The uzi spits outs values 1-64
It first goes into the expr..which divides the uzi stream ( $f1 ) by the length o the table (64) , multiplied by 2pi radians .
This goes into a cosine into ( cold inlet )of float .
The float is banged only when the TBF has written it's first index .
Problem is that the first value is never written .
I've disconnected the order multiple times and the same result occurs .
Only when reloading the patch it works fine ( edit it doesn't )

[uzibug.pd](/uploads/files/1714834042641-uzibug.pd) Insert Code Here

#N canvas 827 239 527 327 12;
#X obj 385 680 tabwrite this, f 39;
#N canvas 0 0 450 250 (subpatch) 0;
#X array this 64 float 2;
#X coords 0 1 64 -1 450 215 1;
#X restore 148 69 graph;
#X floatatom 72 471 5 0 0 0 - - - 12;
#X msg 72 530 \; this color \$1 \;;
#X obj 435 309 bng 60 250 50 0 empty empty Bang\ \  68 30 0 44 #333333 #eeeeee #e43009;
#X obj 385 580 cos;
#X msg 193 532 \; this width \$1 \;;
#X floatatom 193 471 5 0 0 0 - - - 12;
#X obj 385 643 f;
#X obj 435 394 uzi 64, f 30;
#X obj 385 514 expr ($f1/64)*(3.1415*$f2), f 23;
#X floatatom 722 428 5 0 0 0 - - - 12;
#X obj 622 600 t b f;
#X obj 727 319 loadbang;
#X msg 728 394 2;
#X msg 816 360 \; this color 298 \; this width 2 \;;
#X connect 2 0 3 0;
#X connect 4 0 9 0;
#X connect 5 0 8 1;
#X connect 7 0 6 0;
#X connect 8 0 0 0;
#X connect 9 2 10 0;
#X connect 9 2 12 0;
#X connect 10 0 5 0;
#X connect 11 0 10 1;
#X connect 12 0 8 0;
#X connect 12 1 0 1;
#X connect 13 0 14 0;
#X connect 13 0 15 0;
#X connect 14 0 11 0;

@whale-av said:

So is it possible that it was it [cyclone/line~] that you tested in your opening post? .... as you separated the pairs in that screenshot?

No , because cyclone line can only be instantiated with cyclone/line~

In my first post , I separated the pairs in the message because I was pretty sure pd line~ did not accept multiple pairs contrary to what the info bubble said.

After all , vline~ would be my first choice since it's more capable compared to cyclone/line~
It's all good now ,

It's obviously a name clash .
Regular Line~ is instantiated despite the info showng cyclone , for cyclone one should instantiate cyclone/line~
All good

@ddw_music said:

The reference panel says "Origin: cyclone." This tells you that it did not load the vanilla [line~] object -- it loaded the one from cyclone, which is modeled after Max's [line~], which does accept a series of breakpoint pairs.

hjh

It does not accept multiple pairs , even the cyclone one.
This should go to 1 instantlly , to 0 in 200ms, back to 1 in 100mS and back to 0 in 100 ms
It doesn't
As a matter of fact , I think the reference to cyclone is just wrong , because pure data vanilla loads it fine and I don't have any externals at all

Plug data 0.8.3
Hover your mouse over the left inlet
Also right click the object , choose reference and it will aslo show the wrong info

Is this in error in plugdata pop up help ?
It says the line~is capable 128 target-time pairs , afaik only two targets are possible in 1 message box

Three operaotrs in single feedback loop

Yes , indeed confusing .
I never brought up the second discussion , I was only interested in display of the chords
I know how to make abstractions ,
Thanks all fo the suggestions

Different methods of using 1unit sample feedback loops

Why are these important , for doing karplus strong , and for FM operator feedback ( where an operator is a phasor~into cos ~)
The only rules are
1-It needs to be in subpatcher
2- an explicit block~ module has to be inserted 'block~1 '
You can achieve 1 unit feedback with delwrite~ and delread~ ( make sure delay time is 0 )
Or you can use a " tabsend~ tabread~" ,or "tabsend~ tabreceive~" when the tabsend~ method is used , it's crucial that an array is created withe same name .
The size of the array doesn't really matter , since only the first sample of the array is used to write into.
Here are some examples of the different methods
Left is the carrier ( phasor~ into cos~) , right is the modulator with self feedback .
I also added phase shift to the modulator to create a perfect trian gle ,which is only possible with operator feedback and phase shift