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

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

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

@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

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

@gentleclockdivider said:

Regular Line~ is instantiated despite the info showng cyclone

That would be a plugdata bug then, for the Reference feature, you could go log it: https://github.com/plugdata-team/plugdata/issues

hjh

@ddw_music It might not be a bug. Objects should never have the same name but that seems to be how it is.
Plugdata has loaded the vanilla [line~] object, but has picked up the object reference for [cyclone/line~] when it searched for the help file, simply because it found it first? The help files are not built in to the Pd binary. If they were then the problem would not arise, or more likely be reversed and cyclone help would never be found.
But the real problem is the use of the same object name.
Anyway, the author has already spotted this thread and submitted a bug report.

@gentleclockdivider You probably know, but if you set the Pd command window to at least log level 2 (normal) you will see where Pd has searched for an object or a help file. Maybe that is not the same for plugdata, but if it is then you will see all the directories that were searched when looking for the help.
As you discovered, as [line~] is "built-in" to the Pd single binary no search is performed, and the vanilla [line~] will always be loaded unless as you say the cyclone library has been specified.

As you have also found....... [cyclone/line~] does accept a maximum of 128 natoms.......... https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/audio/line.c#L179
.... but as a long list (no commas). It works out separation of the pairs by the odd and even atoms in the list.

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?
You can tell by the right outlet...... but the help message hides where it could be in the screenshot?
It might be worth your time to find out what search paths are operating for your different forks of Pd.
I wonder whether some of them are sharing playlist files or preferences in the registry.
David.

@whale-av said:

Plugdata has loaded the vanilla [line~] object, but has picked up the object reference for [cyclone/line~] when it searched for the help file, simply because it found it first?

If the reference feature is loading help data for a different object from the one that was loaded into a patch, I think that can pretty much be understood only as a bug. I can't think of any reason for that to be designed behavior, and it isn't useful to the end user.

The help files are not built in to the Pd binary.

Fair enough, but this thread is about a specific feature of PlugData that does not exist in pd vanilla -- hence observations about vanilla are probably not directly relevant. (Except... If vanilla always loads help from the right place, then it means the location is in there somewhere, and PlugData just isn't using it correctly here = bug.)

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?

I independently tested the case without commas and found that the behavior is that of the built-in object, not cyclone's.

hjh

@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 ,

in plugdata, check else/envgen~ it's more powerful

yeah, the reference is from cyclon, not that cyclon's got 2 outlets