Re: [PD] Prototype for adding an object browser into Pd Vanilla's core
On 3/10/23 06:57, Alexandre Torres Porres wrote: Hi everyone, I made a prototype of a GUI addition thanks for working on this. that I would really like to have included in the Pd-Vanilla distribution. however, i wonder what makes your plugin different from any other plugin, that warrants its inclusion into main Pd? > I think this is problematic to keep as a plugin as it'll mostly > be missed by users. yes, that is how it is. but it is true for virtually all gui-plugins and externals. (heck, it is even true for Pd itself). so what makes your plugin different from e.g. the "dnd-plugin"? i think (but here i am heavily biased), that a plugin like my tip-of-the-day plugin could solve this general problem (by creating tips that announce especially useful plugins). but even tip-of-the-day is not included with Pd itself :-) (but then, i do have plans to change that.. exactly because it is supposed to solve the problem of pushing new information to the users). Well, if it gets included, I plan to take care of it and do things like insert a new object whenever it comes up as long as I live. I am relatively young and don't have plans to die soon. while i think your engagement is great (and amazing, regarding the amount of work you invest), i think this is really a bad proposal from the "Bus factor" [1] point of view. priorities in life are constantly shifting. we had super-engaged maintainers (of entire Pd-distributions!) who have ceased their Pd-related activity completely (without having "died" or anything similarily drastic; just their life has changed). personally, I do not know what will happen in my life (i'm marginally older than you; and have no intention to die soon either), do you? (sidenote: yes, i do consider the bus-factor with my Pd-involvement an unpleasant problem) Another problem is that I think it is hard to maintain this out of the core and I say this because while my plugin works now, it is already broken for the current master on github, then i think the architecture is broken and it should definitely *not* be included with Pd itself. i think it is really crucial that the structured information on objects (that is: their existence, and the categories they belong to), is not encoded/stored in any *other* place (like your object_tree.tcl file). i think the only maintainable option is really to extract this information from the available objects themselves. consider the "search-plugin". it dynamically gathers all information it needs at startup. why can the object-browser not do the same? consider the "completion-plugin". it dynamically gathers all information it needs at startup. why can the object-browser not do the same? consider my "tip-of-the-day" plugin, which can fetch its data from some online resources (because it's impossible to come up with a tip about plugins that haven't been written yet.) Is anyone bummed out and would have some sort of issue with this functionality? i don't have any objections regarding the functionality. but as long as it requires manually maintaining a database of any change in the objects, i strongly believe that the architecture ought to be reconsidered. gmds IOhannes [1] https://en.wikipedia.org/wiki/Bus_factor OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] phase locked loop
thanks for your answer. as a first project i wanted to explore the possibilites in treating the output of a hexaphonic bass pickup with puredata. a pll oscillator with the bass string as input (filtered to remove unwanted harmonics) sprang to mind. other topics i am currently investigating: -pitch to voltage from the different strings at low latency (difficult with bass frequencies, i took a gr300 guitar synth approach) -proper attack detection -adaptive filtering of the individual strings overtones to remove octave jumps from the pitch to voltage block On Fri, 10 Mar 2023, 00:48 Charles Z Henry, wrote: > Synchronizing oscillators is a good topic and there should be some better > options with digital alone than with simulations of the analog circuits. > > Synchronization in natural systems involves a phase-resetting oscillator. > The key behavior is the oscillator responds to input events, by adjusting > its phase by an amount that depends on the current state of the > oscillator. This is enough to produce synchronization within a small range > of nearby frequencies, by itself, but adjusting frequency is also possible. > > What did you have in mind? Any specific behavior it needs to have? > > > > > > On Tue, Mar 7, 2023, 4:01 PM Simon Iten wrote: > >> hi list, >> >> does somebody have a patched version of a PLL (phase locked loop) in PD? >> or building blocks of it... >> >> cheers >> >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] taking over completion-plugin and releasing version 0.48.0
On 3/7/23 02:52, Alexandre Torres Porres wrote: Hi, I forked completion-plugin and released an update (0.48.0), which is in deken. thanks for taking care of this. can you please open the issue tracker on your github repository? gfdsmr IOhannes OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] phase locked loop
Synchronizing oscillators is a good topic and there should be some better options with digital alone than with simulations of the analog circuits. Synchronization in natural systems involves a phase-resetting oscillator. The key behavior is the oscillator responds to input events, by adjusting its phase by an amount that depends on the current state of the oscillator. This is enough to produce synchronization within a small range of nearby frequencies, by itself, but adjusting frequency is also possible. What did you have in mind? Any specific behavior it needs to have? On Tue, Mar 7, 2023, 4:01 PM Simon Iten wrote: > hi list, > > does somebody have a patched version of a PLL (phase locked loop) in PD? > or building blocks of it... > > cheers > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Sometimes all data-structures are redrawn
On Thu, 2023-03-09 at 22:14 +0100, João Pais wrote: > > > > > > Redraw times when opening patches (counted in my head): > > - 2 - 15s > > - 3 - 0s > > - 4 - also around 15s, this seems to be the reference value no matter > which other patches are opened. > > This on W10, Thinkcentre, 2x2Ghz, 16Gb Ram. Ok, thanks for testing. > My clicktracker patch (which is one GOP object) takes ages to load > now, > it wasn't like that a couple of months ago. (nothing changed in it > during this time) Interestingly, only redrawing takes long time with data structures. When loading the example patch, the scalars are drawn almost instantaneously (and they are created on the fly at loadbang). So, I suspect slower loading time is a separate issue, probably unrelated to the redrawing. You could load your patch in a previous version of Pd to check if it makes a difference. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
