[PD] Slider/Knob

Hello List, I would like to use knobs instead of sliders, where can I find them? Cheers Clemens ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Re: [PD] Slider/Knob

I recommend mknob from moonlib, but make sure you get the latest version from deken for pd >= 0.47 Christof > Gesendet: Freitag, 07. September 2018 um 12:59 Uhr > Von: Clemens > An: Pd-list@lists.iem.at > Betreff: [PD] Slider/Knob > > Hello List, > > I would like to use knobs instead of slider

Re: [PD] Slider/Knob

Thanks for recommending mknob ;-) I'd like to do an update of moonlib soon, as it has received some improvements: sfread2~ understands a new [index( message (thx to Antoine Villeret), and mknob now better supports zooming. About the latter, I'd like to hear your opinion (you all mknob users...) a

Re: [PD] Slider/Knob

Hi all, i'm trying to move all my music apps to 64 bit on Windows (it's the standard and more softwares are adbandoning the 32 bit version) I would really like to try both moonlib and the oliver's abtraction. But everything rely on 32 bits library. Hope to get some 64x version soon. Pd 0.48.2 works

[PD] Compiling externals for w64. (was : Re: Slider/Knob)

Hi Alfonso, Back in March, when we got w64 Pd to work and also we tweaked the nuts and bolts of pd-lib-builder, I did some preliminary work on compiling many libs (all 00-extended) for w64. I got in to troubles and found some solutions. May be this week (or next) I'll revisit my files and try t

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Thanks Lucas, i already have a msys2 with mingw64 set on my system. Do you suggest me do go that way instead of VS or Code::Blocks with mingw64 Il ven 7 set 2018, 16:07 Lucas Cordiviola ha scritto: > Hi Alfonso, > > Back in March, when we got w64 Pd to work and also we tweaked the nuts and > bol

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Yes. I suggest using MinGW64. Pd-lib-builder is ready for that. You are on your own if you use VS and hit all kind of troubles that only and expert can deal (c runtimes, etc, etc). I never used code::blocks but it should work. I had no trouble with Msys2 and I like it. If you want a test you c

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Awesome, thanks! www.elgallorojorecords.com soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone On Fri, Sep 7, 2018 at 4:41 PM Lucas Cordiviola wrote: > Yes. I suggest using MinGW64. Pd-lib-builder is ready for that. You are > on your own if you use VS and hit all kind of trouble

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

And if you want to try compiling a single external say foo.c Get familiar with the makefile: # Makefile for mylib lib.name = mylib class.sources = foo.c datafiles = foo-help.pd README.txt LICENSE.txt include Makefile.pdlibbuilder https://github.com/pure-data/pd-lib-builder#basic-

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Cool, thanks! I guess this implies clone the pd git insed the msys2 scope folder, so that pd lib builder can find all the pd headers. am i right? a. www.elgallorojorecords.com soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone On Fri, Sep 7, 2018 at 4:55 PM Lucas Cordiviola wrot

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

no, you can put the git repo anywhere you like. msys2 comes with special shell launchers which set up the necessary paths. they're called "MSYS2 MSYS shell launcher" (default shell), "MSYS2_MINGW32 shell launcher" (for compiling 32bit binaries) and "MSYS2_MINGW64 shell launcher" (for compiling 6

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Thanks Christof 1. For some reason the latest pd install (64 bit) doesn't have all the headers and sources in the pd/src folders 2. I don't really understand very well this launcher thing, so i don't understand how i can refer to a general Win system folder from inside the MSys2 shell. www.elgal

Re: [PD] Slider/Knob

Hi, to be honest, I never found it to be a big problem. I'm not too sure about the three outlet solution, I think it's indeed a bit far-stretched :-) what I would suggest is to give the user a visual hint (i.e. draw the rect borders and the iolets)- but only when the user hovers over the knob wh

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Just open “Msys2 MinGW64 bit” from the start menu. in case you have both 32 and 64 bit Pds on your system you have to make sure pd-lib-builder finds the 64bit one. use: make PDDIR=full/path/to/64bit/pd(folder) PDLIBDIR=path/youwanttoplacethecompiledobject install PDDIR=full/path

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

> 1. For some reason the latest pd install (64 bit) doesn't have all the > headers and sources in the pd/src folders for most externals, you should only rely on "m_pd.h". all other headers are considered not public and therefore unsafe to use. > 2. I don't really understand very well this launc

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Yes is what i do. Opening "Msys2 MinGW64 bit" from the start menu. I mean that as far as i remember is not so straightforward to refer to windows file system from inside the Msys2 console. So given that my pd dir is in the windows root C:\ as far as i remember is not so easy to refer to such "exte

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

Oh thanks Christof ...simple almost unoticeable thingie :-) www.elgallorojorecords.com soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone On Fri, Sep 7, 2018 at 5:37 PM Christof Ressi wrote: > > 1. For some reason the latest pd install (64 bit) doesn't have all the > headers and

Re: [PD] Compiling externals for w64. (was : Re: Slider/Knob)

go ahead with make PDDIR=c:/path/to/64bit/pd(folder) ... :) Mensaje telepatico asistido por maquinas. On 9/7/2018 12:41 PM, alfonso santimone wrote: Oh thanks Christof ...simple almost unoticeable thingie :-) www.elgallorojorecords.com soundcloud.com/alfonsos

Re: [PD] Slider/Knob

> > a visual hint (i.e. draw the rect borders and the iolets)- but only when > the user hovers over the knob while the glist is in editmode > you mean like the little square of the canvas object? yes, I like the idea. I'll try this soon, thanks! Antoine Rousseau http://www.metalu.net

Re: [PD] Slider/Knob

> you mean like the little square of the canvas object? kind of, except that my_canvas only shows the square when the object is selected. of course that's also possible! my idea was to show it when you hover the object in editmode, so you don't have to explicitly select the object to see where

Re: [PD] Slider/Knob

I see; why not even showing outline and iolets as soon as the patch is switched to edit mode? But I must admit I don't know how to detect these events (object is hovered /or/ patch switches to /from edit mode). I'll try to find existing similar code, but maybe you have some pointers? Antoine Rouss

Re: [PD] Slider/Knob

OK I just tried and mknob_newclick allows receiving hovering as you said before. Antoine Rousseau http://www.metalu.net __ http://www.metaluachahuter.com/ Le ven. 7 sept. 2018 à 19:32, Antoine Rousseau a écrit : > I s

Re: [PD] Slider/Knob

cool! > why not even showing outline and iolets as soon as the patch is switched to > edit mode? the only type of object inside the canvas which gets notified on editmode changes is T_TEXT (to toggle the vertical line on the right), so AFAICT it's impossible to achieve without nasty tricks (se

Re: [PD] Slider/Knob

too bad, newclick(...) is never called when in edit mode... so: no hovering detection when in edit mode, no way to (easily) detect edit mode on/off switching... back to the starting point. maybe i will... do nothing more ;-) Antoine Rousseau http://www.metalu.net __ http://ww

Re: [PD] Slider/Knob

D'oh.. well, as i said, the floating iolet never bothered me after all :-) > Gesendet: Samstag, 08. September 2018 um 00:13 Uhr > Von: "Antoine Rousseau" > An: "Christof Ressi" > Cc: Pd-list > Betreff: Re: Re: Re: Re: [PD] Slider/Knob > > too bad, newclick(...) is never called when in edit mode