Sorry , if it was not clear .
It was indeed an abstraction ( calling another pd patch ) and not a subpatch

I am havng an issue here
A subpatcher with two arrays called $0-regina and $0-felina for locality
I can switch between the tables by using float $0 and then into set message "$1-felina" "$1-regina"
The issue however , once outside the subpatcher , I can not send color and width data to the tables using a send module called "$0-regina" , "$0-felina"
Inside the patcher it works
Help appreciated
Here's the subpatcher

```

Insert Code Here

@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

@whale-av said:

@gentleclockdivider "Let's recap , a chord ( thus separate incoming midi notes perceived as a chord ) goes into pure data , I want to extract the midi note values .
UNpack -only unpacks last received note+velocity , that's why I wrote that an object that detects the time between incoming events could be the solution .
SO let's say I play a simple c min (midiin) , which has the midi note nr's 48 , 51 , 55 ....I want these these to appear in separate numboxes ."

[unpack] produces all the note numbers...... but you only see the last..... a [print] will show them.
As I said at the start of this thread, [poly] will separate them for you as it indexes the notes.
You could then use [route] to separate them but [clone] is more useful as you can clone a synth inside if you wish.
The indexes from [poly] can be used to allocate the notes to the clones, and [poly] then ensures that you have no hanging notes as the noteoff messages are allocated the same index.

As the idea of a chord is human and has no meaning in Pd, midi, or even on a keyboard, why would you need to group the notes together with a timer or a threshold.... I am just curious...
To correct bad keyboard technique...?

The method using [poly] and [route] is shown in your Pd/doc folder....... Pd/doc/7.stuff/synth/1.poly.synth.pd .... since at least 2011.
David.

I reall think we have a communication error here .
I know that a chord does not exist in pure data -midi etc...and that it's a sequential message of single notes , I have expresed that in my first post .
I am also aware that only the last of the messages is shown by the unpack module .

• quote-

As the idea of a chord is human and has no meaning in Pd, midi, or even on a keyboard, why would you need to group the notes together with a timer or a threshold.... I am just curious...
To correct bad keyboard technique...?
-unquote -
Bad keyboard technique ??
I just wanted pure data to SHOW all incoming midi notes that make up the chord , not in the console but in the structure view ., , your treshold value example did that .
Why is it so bizarre to ask for that , max msp has a dedicated object for exactly that , says enough .

Thanks ,
And how would one do it with the poly object ( if possible ) ?

The borax object gives all the info ,nr of note on's that are held , timing between notes ( chord remember ) and the note nr ( again only the last one in the stream ).
There has to be some kind of module that stores all the incoming-separate notes so we can then later extract the note values

The first part of this video shows exactly what I am dealing with , max msp has an object called quicktresh which detect all the incoming notes ( if played fast like a chord ) and shows the notes numbers .
This object probably uses an internal timer to seperate the incoming notes , hence see my first post why I think such an object would solve my problem
So ..how to do this in pure data ?

@whale-av said:

@gentleclockdivider You should post your incoming message, as there is no such thing as a chord in midi.
It is likely that it is a series of note velocity pairs arriving in a fast sequence.
If so, then [poly] and [clone].
If not there will be a solution, but we cannot help without knowing the problem.
David.

Did you read my first post ?
I am aware that midi is a serial protocol and chords are just separate notes send after each other
-quote-
Since a chord is essentialy multiple messages send in serial order
-unquote-
Let's recap , a chord ( thus separate incoming midi notes perceived as a chord ) goes into pure data , I want to extract the midi note values .
UNpack -only unpacks last received note+velocity , that's why I wrote that an object that detects the time between incoming events could be the solution .
SO let's say I play a simple c min (midiin) , which has the midi note nr's 48 , 51 , 55 ....I want these these to appear in separate numboxes .

So just using pd vanilla objects won't cut it ?
Edit , I mean poly is part of vanilla but I have hard time how to set it up to seperate the incoming notes ( chord )

How does one unpack a chord into the separate (note ) values ?
Since a chord is essentialy multiple messages send in serial order , the unpack is of no use ( it unpacks a single note +velo )
An object with a time interval between incomming messages would solve it , but I cant't find any

@seb-harmonik.ar
I see , I wrongfully assummed that the table y range automatically disregards the negative parts , while in fact it's just not shown ( in case of plugdata ) but it's still read out .

@oid
No idea if your trying to be funny or not