Have you looked at ds-arrays at all? You can quantize the values and
change them in one go as you describe (see attached).
-Jonathan
--- On Mon, 3/1/10, volker böhm <vboehm(a)gmx.ch> wrote:
> From: volker böhm <vboehm(a)gmx.ch>
> Subject: Re: [PD] integer values
> To: pd-list(a)iem.at
> Date: Monday, March 1, 2010, 7:26 PM
> thanks everybody for your
> suggestions.
>
> matteo's example is close to what i need.
> thanks for this trick, i'd probably never have thought of
> stacking two sliders on top of each other.
>
> i tried the same thing with an array (to have an arbitrary
> number of sliders grouped together)Â - but it doesn't
> work :(
>
> [#many] looks interesting. i haven't fully explored its
> possibilities. my impression is, it's good for clicking, but
> dragging to change multiple values in one go, seems not
> possible (see my poor example below).
>
> On 01.03.2010, at 11:27, João Pais wrote:
>
> > can you put an example of the patch you're doing? it
> might be easier to give suggestions in that way.
>
> it's basically what matteo has posted - a slider, with
> values quantized to integer steps.
> why integers if you can have floats, you might ask:
> suppose you wanted to cut a sample into 8 equal slices, and
> then want to specify the order in which to playback the
> slices by a specific sequence. in this szenario i'm not
> interested e.g. in the 2.4th slice, i want either slice
> number 2 or 3.
> therefore i'd like to have an interface that allows only
> integer values and nothing in between.
>
> this is just a simple example, but maybe it shows, why such
> a thing might be useful from time to time.
>
> ok, one slider is fine, only for making sequences it would
> be great to have multiple sliders combined, to be able to
> drag horizontally for easy editing of multiple values.
>
> so here goes my akward design of an integer multislider
> thing:
>
> #N canvas 78 22 553 384 10;
> #N canvas 0 0 450 300 (subpatch) 0;
> #X array a 8 float 3;
> #A 0 1 5 3 5 2 4 6 2;
> #X coords 0 7 8 0 200 140 1;
> #X restore 71 53 graph;
> #X obj 344 207 tabread a;
> #X obj 344 121 until;
> #X msg 344 98 8;
> #X obj 344 149 counter 0 7;
> #X obj 344 229 + 0.5;
> #X obj 344 253 int;
> #X obj 344 278 tabwrite a;
> #X obj 344 176 t f f;
> #X text 41 183 0 --;
> #X text 43 46 7 --;
> #X obj 344 73 metro 100;
> #X obj 344 50 tgl 15 0 empty empty empty 17 7 0 10 -262144
> -1 -1 1
> 1;
> #X text 62 21 click and drag to edit values with mouse;
> #X obj 344 20 loadbang;
> #X connect 1 0 5 0;
> #X connect 2 0 4 0;
> #X connect 3 0 2 0;
> #X connect 4 0 8 0;
> #X connect 5 0 6 0;
> #X connect 6 0 7 0;
> #X connect 8 0 1 0;
> #X connect 8 1 7 1;
> #X connect 11 0 3 0;
> #X connect 12 0 11 0;
> #X connect 14 0 12 0;
>
>
>
>
> _______________________________________________
> Pd-list(a)iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
Hi IOhannes,
It would be really nice to have a proper armel version, I will also try to build one but please let us know as well if anybody has a luck on that.
Koray.
On Feb 27, 2010, at 10:52 PM, pd-list-request(a)iem.at wrote:
> Message: 10
> Date: Sat, 27 Feb 2010 21:52:17 +0100
> From: IOhannes m zm?lnig <zmoelnig(a)iem.at>
> Subject: Re: [PD] Pd-anywhere on openmoko/debian
> To: pd-list <pd-list(a)iem.at>
> Message-ID: <4B898601.9010101(a)iem.at>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> IOhannes m zm?lnig wrote:
>> hi
>>
>> i tried to install the Pd-anywhere packages on my debian(armel)-running
>> openmoko, but the binaries immediately fail with "illegal instruction".
>
> packages = pda_0.6-4_armel.deb (debian package from sf)
> binaries = /usr/bin/pd and /usr/lib/pd/bin/pd-gui
>
>
>> does anybody have a version of PDa at hand, that runs on debian/armel?
>
> btw, the openmoko package (.opk) used to run fine on fso (i haven't
> tried to run them on my new debian installation though)
> what platform is the debian/armel package supposed to run on? (my
> installation is debian/armel)
>
> fgamdsr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkuJhgAACgkQkX2Xpv6ydvTLZgCgsGSxFt/SXjVOoyUlOfDuSSvY
> oRwAmwdIHc9qk3ILt5Jl9vSde/F8rSbO
> =jLP7
> -----END PGP SIGNATURE-----
>
>
-------------------------------------
M.Koray TahiroÄŸlu
Media Lab,
Aalto University,
School of Art and Design
http://mlab.taik.fi/~korayt
tel: +358 45 233 6272
Hi,
0.42.5-3 deb had some dependence problems with libc6 version, which blocks all the tcl/tk issues to be solved. I did not have any luck with pda 0.6-armel.deb at all. On the other hand, vanilla seems like the most promising, I will try to put my hands on this whenever I will have time. It would be nice to have a proper running version in Maemo.
Koray
On Feb 27, 2010, at 1:00 PM, pd-list-request(a)iem.at wrote:
> Message: 3
> Date: Fri, 26 Feb 2010 01:39:09 -0500
> From: Umberto <umberto.torrez(a)gmail.com>
> Subject: Re: [PD] Puredata on maemo
> To: Pure data list <pd-list(a)iem.at>
> Message-ID: <1267166349.4165.9.camel(a)localhost.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> ? Hi Hans, Koray? i installed pda 0.6-4 armel.deb on Meaemo 5, the application? runs but i cant get any sound
> i have 2 audio drivers OSS and ESD when i try OSS i get this in the shell OSS:
> ? SNDCTL_DSP_CHANNELS failed /dev/dps
>
> ? and with ESD i get this :
> ? error at esd open:0
>
> ? when the input and output channel on esd to 1 i dont get any error message , but
> ? pd is still not making any sound.
>
> ? Any idea?
>
> ? Koray did you had any luck ?
>
> Ive also tried pureda 0.42.5-3 without any luck , it doesnt compile
>
>
>> ----- Original message -----
>>>
>>> You should be able to run the armel version from Debian
>>>
>>> http://packages.debian.org/sid/puredata
>>>
>>> .hc
>>>
>>> On Feb 18, 2010, at 4:44 AM, Koray Tahiro?lu wrote:> >
>>>>
>>>> Hei Hans, Umberto,
>>>>
>>>>
>>>> At the moment I am trying to install vanilla on Maemo 5, I have some?
>>>> problems with other dependencies, but lets see if it will be?
>>>> possible to install Pd vanilla directly to Maemo, I will try your?
>>>> current release as well.
>>>>
>>>> Koray
>>>>
>>>>
>>>> On Feb 18, 2010, at 11:05 AM, pd-list-request(a)iem.at wrote:
>>>>
>>>>> Message: 5
>>>>> Date: Thu, 18 Feb 2010 02:33:43 -0500
>>>>> From: Hans-Christoph Steiner <hans(a)at.or.at>
>>>>> Subject: Re: [PD] Puredata on maemo
>>>>> To: Umberto <umberto.torrez(a)gmail.com>
>>>>> Cc: Pd list <pd-list(a)iem.at>
>>>>> Message-ID: <FEA18C1C-A12A-468B-BA63-C06EBB27F2D8(a)at.or.at>
>>>>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>>>>
>>>>>
>>>>> Hey Umberto,
>>>>>
>>>>> welcome!? You can run Pd on Maemo 4.1 so it should work on Maemo 5.
>>>>> We're working on updating the mobile version of Pd, so perhaps a?
>>>>> Maemo
>>>>> 5 build will come out of that.? Here's the current release:
>>>>>
>>>>> http://pd-anywhere.sourceforge.net/release/maemo/
>>>>>
>>>>> .hc
>>>>>
>>>>> On Feb 15, 2010, at 3:07 AM, Umberto wrote:
>>>>>
>>>>>> Hi, im new in the list , i would like to know if its possible to run
>>>>>> pd linux mobile devices like maemo 5 or android ,do anybody have
>>>>>> tried that , if not how difficult would it be?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pd-list(a)iem.at mailing list
>>>>>> UNSUBSCRIBE and account-management ->
>>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>>
>>>>
>>>> -------------------------------------
>>>> M.Koray Tahiro?lu
>>>> Media Lab,
>>>> Aalto University,
>>>> School of Art and Design
>>>> http://mlab.taik.fi/~korayt
>>>> tel: +358 45 233 6272
>>>>
>>>
-------------------------------------
M.Koray Tahiroglu
Media Lab,
Aalto University,
School of Art and Design
http://mlab.taik.fi/~korayt
tel: +358 45 233 6272
I'm not sure this might solve your problem, but it can suggest a workaround
- given I correctly understood your problem.
Check Pd browser > 5.reference > mapping > stepper-help.pd
thanks for your responses.
>
> On 28.02.2010, at 15:19, Derek Holzer wrote:
>
> > You could use a array/table with as many elements as you need
> > sliders, and use [int] to quantize them integers.
>
> that's what i wanted to use in the first place. quantizing the table
> values _after_ output, is of course possible, but then the
> quantisation is not graphically visible, which makes for a lame
> interface.
>
> >
> > Most GUI elements give "integers" already, for example a default
> > slider gives 0-127. The type is float but the output values are all
> > without a decimal, unless you change the size or range of the slider
> > of course, so for your purposes you could consider them integers.
>
> ja, but changing the range is what i'd often have to do, e.g. having
> the user choose a step number between 0 and 7.
> i tried quantizing the slider output and to use the set message to
> immediately set the quantized value back into the fader for display,
> but didn't get any usable results.
>
>
> On 28.02.2010, at 15:48, Frank Barknecht wrote:
> >
> > I once wrote a wrapper around arrays as [g_pattern32]:
> > http://more.rjdj.me/2009/06/23/editing-drum-patterns-in-rjdj/ where
> > you can
> > easily set table values with a number box which moves in integer
> > steps as
> > default.
>
>
> thanks for the link. yes, this is certainly usable. but i'm still not
> completely happy with this approach, either.
> i think a well designed interface allows viewing and editing of the
> data in the same location.
>
>
>
> volker.
>
--
Marco Donnarumma aka TheSAD
Independent New Media Arts Professional, Performer, Teacher - Edinburgh, UK
LAB: http://www.thesaddj.com | http://cntrl.sourceforge.net |
http://www.flxer.net
EVENT: http://www.liveperformersmeeting.net
> i tried quantizing the slider output and to use the set message to
> immediately set the quantized value back into the fader for display,
> but didn't get any usable results.
Yeah, I tried that too, and the results are funny. I didn't quite expect
it to work with a default "steady on click" slider, but I did expect it
to work with a "jump on click" slider. The problem is that after
clicking, when you drag, the "jump on click" slider behaves exactly like
a default one.
However, have a look at the attached proposed workaround. I use two
sliders one on top of the other, and take advantage of the fact that in
Pd the gui object on the background catches mouse interaction, not the
one on the front.
The main patch is "test.pd", while the other one is the abstraction used
to control the slider.
Look at the "send" and "receive" properties of the two sliders.
Is this an aproximation to what you were trying to do?
--
Matteo Sisti Sette
matteosistisette(a)gmail.com
http://www.matteosistisette.com
> when dynamically creating
> signal-processing objects or abstractions, the dsp graph is not
> automatically recompiled
[...]
> I can't
> recall if it is considered a feature or a bug, but probably it
> doesn't matter, since dynamic object creation is not officially
> supported.
[...]
> Actually, when creating a tilde object or an abstraction, that
> processes
> signals, dynamically it's not taken into account for the currently
> used
> dsp graph. However, when you create the second instance (or any other
> tilde object), the first one is taken into account, but not the
> second.
This is _not_ only with dynamically created objects.
It also happens with manually-created instances of abstractions
containing dsp objects.
See the attached patch: open "test.pd", it contains a [catch~ audio]
connected to the dac.
Then create in it an instance of [myabs~ 500]: it contains an osc
connected to a [throw~ audio], and $1 is used as the frequency.
You will hear nothing.
Then create a [myabs~ 700]: now you'll start to hear the previously
created one, but not the second. And so on.
So the bug also affects "officially supported" patching and it does
matter, though only for "live patching" (everything works fine when you
load a saved patch). When you know it it's not a major issue (or an
issue at all), but until you realise it, it can be quite confusing when
editing the patch and try to figure out what's going on...
--
Matteo Sisti Sette
matteosistisette(a)gmail.com
http://www.matteosistisette.com
> so how do you determine whether the loop is an infinite one?
> and who will pay the numerous custodians in the galleries needed
> to click on "yes, i really want this loop?".
You have a point. Better stated, you are absolutely right.
The second solution I mentioned is definitely better.
Which was more or less the same that you mention:
> that it would be nice to be able to halt the virtual
> machine without quitting Pd.
Anyway Pd should at least always allow you to save patches and
gracefully quit.
> it would also be nice to have a step-debug mode...
I would be happy with just being able to find not-only-the-last error
--
Matteo Sisti Sette
matteosistisette(a)gmail.com
http://www.matteosistisette.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi
i tried to install the Pd-anywhere packages on my debian(armel)-running
openmoko, but the binaries immediately fail with "illegal instruction".
i have no toolchain ready, to compile PDa myself, and unfortunately i
cannot even install tools like gdb on the device (it's only a 512MB
card, and that one is _pretty_ full just with the stock debian+phoneapps)
does anybody have a version of PDa at hand, that runs on debian/armel?
dfgamdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuJhNMACgkQkX2Xpv6ydvRQswCdHmCArqpYGph9DgRSIxiHK3U5
aMMAn39jQSPxjtExZKPlSx67RPIE4B2d
=61pL
-----END PGP SIGNATURE-----