@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

@whale-av said:

@gentleclockdivider No idea. The only [uzi] I know of outputs only bangs.
It's not a good idea to have objects or abstractions with the same names.
If it is an abstraction that you made maybe call it [g-uzi] so that [uzi] cannot be loaded by mistake.
Is it one you made?,
Or please tell us where it can be found.
Or explain its functions so that we can try to understand.

When you have problems it is a good idea to upload the patch.
That would be very helpful.
No-one really wants to spend time making it again so as to see what is going on.
David.

It's the uzi rfom cyclone library , no abstraction
THe right outlet of uzi = nr of bangs whichcan de used to adress the index points of a table
Edit ...now I've made one with until to be compatible with PD vanilla

I wrote a sine into a table
Output of modulo / by table length , and mutltipled by 2pi radians .( complete sine )
Then I powered the sine exponent 13 , the table is set to range 0-1 , which is reflected in the table display .
So only the positive part of the cycle is shown (and should be read )°
Reading the table with tabread~ , The osciloscope clearly shows the signal is bipolar , iow the -1 part of the array is also read out .
How is this possible
SO even if the table is restitricted to range 0-1 , it will not cut off the negative portion of -1/+1 wave .
Is this expected behaviour or a bug
I aso noticed that the array in plugdata doesn't show the negative range but pure data vanilla does ,, both arrays are 0,+1 and both output -1,+1

Same with just an increasing function ,console starts at 225 , again all 1024 points are adressed perfectly
Could it be there is a limit on the numbers of lines displayed in the console , in this case 1024-225 =799