Pd-list May 2016

pd-list@lists.iem.at

78 participants
146 discussions

[initbang] won't bang..
by Alexandros Drymonitis 25 May '16

25 May '16

I' m just trying out [initbang] downloaded from here https://git.iem.at/pd/iemguts but it doesn't bang on load of an abstraction... I'm using it with Pd-0.47-0 on Debian Jessie. The object compiled fine and is created, but I get no bang... there must be something I'm missing..

2 6

convert float to bit
by Alexandre Torres Porres 24 May '16

24 May '16

hi, anybody know of an external that converts float to bits in pd? something like http://www.h-schmidt.net/FloatConverter/IEEE754.html cheers

3 2

Re: [PD] [initbang] in Pd.0.47
by Jérôme Abel 24 May '16

24 May '16

> I'm not clear whether initbang's banging whtn a patch is opened > should be regarded as a bug or not. For my use, it is not a bug. It is a very useful behavior. It can be used as a [loadbang] or bang when the abstraction is dynamically added. For the malinette framework, it allows me to have just one [initbang] for each object. Best, Jerome

2 1

[iemnet/tcpclient] blocks Pd when connecting to non-reachable host
by Roman Haefeli 24 May '16

24 May '16

Hey I only noticed that now. If you are unlucky enough to connect to a host that is configured to simply drop (as opposed to refuse) a connection on a non-existing or hidden port, Pd is blocked for as long as the requests reaches a time out. This can be very long, up to a few minutes and you can't do anything in the GUI (e.g. telling [tcpclient] to drop the connection) while it is waiting for the connection to establish. Pd's [netsend] behaves the same, but this one I was expecting not to be threaded. Roman

1 0

sensing GOP resize
by Liam Goodacre 24 May '16

24 May '16

Vanilla now has the nice feature that lets you resize objects with the mouse. Is there any way of detecting this from inside the patch? It doesn't turn up in iemguts/receivecanvas, but if I could somehow receive the new coordinates, then I could program the patch to adapt to the new size. Alternatively, is there some way to query the GOP area from within the patch, a bit like [get_pos( to a canvas? I know this is optimistic, but I thought I'd ask. PS. I know all about [donecanvasdialog(. In this situation, I don't think it will help.

3 3

Re: [PD] [L2Ork-dev] problems with footils fluid~
by Ivica Ico Bukvic 23 May '16

23 May '16

How recent of a gcc does Manjaro use? It seems this may be either sandy bridge CPU peculiarity (there was another one pertaining to locking and unlocking where double unlock on a pthread caused crash on sandy bridge but no other cpus) where it may be more sensitive to things programmers should not be doing in the first place, or this may stem from the increased sensitivity in the new gcc. At any rate, after studying the code, it seems that a struct settings is instantiated (containing all the default init settings for the synth), passed along to instantiate the synth but then also immediately afterwards it is freed even though the synth instantiates multiple threads and it may be that the data is freed before the other potential thread that may be in charge of actually instantiating the synth may be done reading data within it (I haven't had a chance to study the code enough to fully understand how the threading is done within the libfluidsynth itself). At any rate, I changed the fluid~ code now where settings is a private member of the class and is freed only once the actual entire synth is freed, which should hopefully also solve the problem of the memory leak. Best, Ico On 5/23/2016 7:39 AM, Albert Graef wrote: > Hi Ico, > > I just tested it on Manjaro (Arch) 64 bit, using various different > soundfonts and fluidsynth 1.1.6 and it works without a hitch for me. > Maybe a broken libfluidsynth on Ubuntu? > > Albert > > On Mon, May 23, 2016 at 12:31 AM, Ivica Bukvic <ico(a)vt.edu > <mailto:ico@vt.edu>> wrote: > > All, > > It appears since sometime earlier this year (possibly with upgrade > to Ubuntu 15.10 and newer), fluid~ external crashes as soon as you > enable dac~. It worked perfectly fine before. The backtrace is > fairly cryptic suggesting something is wrong with the > libfluidsynth. Yet, other apps that use it work just fine (e.g. > Qsynth). To make matters more complicated, fluid~ uses flext > library, although other externals work fine with the current > version of flext. > > Below is the gdb backtrace: > > #0 0x0000000000000000 in ?? () > #1 0x00007fffdab6e691 in fluid_hashtable_lookup () > from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 > #2 0x00007fffdab6f51e in ?? () > from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 > #3 0x00007fffdab71448 in fluid_settings_getint () > from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 > #4 0x00007fffdab6a026 in fluid_LADSPA_run () > from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 > #5 0x00007fffdab7d3b7 in fluid_rvoice_mixer_render () > from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 > #6 0x00007fffdab8399d in fluid_synth_write_float () > from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 > #7 0x00007fffdae28908 in fluid::m_signal(int, float* const*, > float* const*) () > from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux > #8 0x00007fffdae29fcb in flext_dsp_multi::dspmeth(long*) () > from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux > #9 0x00000000004b3bc5 in dsp_tick () at d_ugen.c:336 > #10 0x00000000004a3093 in sched_tick () at m_sched.c:385 > #11 0x00000000004a34be in m_pollingscheduler () at m_sched.c:485 > #12 m_mainloop () at m_sched.c:563 > > Is this a know issue? It wasn't a problem until I upgraded to > 15.10 (from 14.04) and it seems 16.04 (64bit) is also problematic. > Has anyone had any luck recently with the fluid~ external? > > _______________________________________________ > L2Ork-dev mailing list > L2Ork-dev(a)disis.music.vt.edu <mailto:L2Ork-dev@disis.music.vt.edu> > http://disis.music.vt.edu/listinfo/l2ork-dev > > > > > -- > Dr. Albert Gr"af > Computer Music Research Group, JGU Mainz, Germany > Email: aggraef(a)gmail.com <mailto:aggraef@gmail.com> > WWW: https://plus.google.com/+AlbertGraef > > > _______________________________________________ > L2Ork-dev mailing list > L2Ork-dev(a)disis.music.vt.edu > http://disis.music.vt.edu/listinfo/l2ork-dev

1 0

[PD-announce] Open call for collaborators. Interactivos?’16: Possible Worlds workshop. Medialab-Prado
by Producción Medialab-Prado 23 May '16

23 May '16

Join now the workshop Interactivos?’16: Possible Worlds. Creative and Collaborative Uses of Digital <http://medialab-prado.es/article/interactivos16-mundos-posibles-colaborador…> for a unique collaborative experience! There is still room at the Hostel!!. [Medialab-Prado <http://medialab-prado.es/> from May 31st to June 12th]. _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

problems with footils fluid~
by Ivica Bukvic 23 May '16

23 May '16

All, It appears since sometime earlier this year (possibly with upgrade to Ubuntu 15.10 and newer), fluid~ external crashes as soon as you enable dac~. It worked perfectly fine before. The backtrace is fairly cryptic suggesting something is wrong with the libfluidsynth. Yet, other apps that use it work just fine (e.g. Qsynth). To make matters more complicated, fluid~ uses flext library, although other externals work fine with the current version of flext. Below is the gdb backtrace: #0 0x0000000000000000 in ?? () #1 0x00007fffdab6e691 in fluid_hashtable_lookup () from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 #2 0x00007fffdab6f51e in ?? () from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 #3 0x00007fffdab71448 in fluid_settings_getint () from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 #4 0x00007fffdab6a026 in fluid_LADSPA_run () from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 #5 0x00007fffdab7d3b7 in fluid_rvoice_mixer_render () from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 #6 0x00007fffdab8399d in fluid_synth_write_float () from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1 #7 0x00007fffdae28908 in fluid::m_signal(int, float* const*, float* const*) () from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux #8 0x00007fffdae29fcb in flext_dsp_multi::dspmeth(long*) () from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux #9 0x00000000004b3bc5 in dsp_tick () at d_ugen.c:336 #10 0x00000000004a3093 in sched_tick () at m_sched.c:385 #11 0x00000000004a34be in m_pollingscheduler () at m_sched.c:485 #12 m_mainloop () at m_sched.c:563 Is this a know issue? It wasn't a problem until I upgraded to 15.10 (from 14.04) and it seems 16.04 (64bit) is also problematic. Has anyone had any luck recently with the fluid~ external?

1 1

[initbang] in Pd.0.47
by Jérôme Abel 22 May '16

22 May '16

Hi, I notice a "new" behavior of the [initbang] object. When I put directly in an abstraction, it sends a bang, but when I put it in a subpatch into the same abstraction, it does not. Is it the new and fixed behavior ? Thanks, Jerome

5 7

Re: [PD] how to get GEM working in Vanilla?
by rolfm＠dds.nl 21 May '16

21 May '16

@ IOhannes > afaik, both /downloads/gem and deken only provide Gem-0.93.3 (not > newer) > for W32... so, that's what i'm using > >> >> Vanilla 46.7 shows the same problem with Gem >> >> to me it looks like the lib is found, but the creation of the objects >> fails. >> for [gemwin] there exists a gemwin.pd in the lib: the object box is >> drawn like it is ok, but the 'content' cannot be created (list of >> errors >> in Pd-console). > > ...but all the details of your report show that you are using some > 0.94git snapshot see above. > > OR > > that you simply failed to load the Gem binary. > did you get the splash-screen telling you that Gem has been loaded? no splash-screen. > > > i suspect this all to do with libdir. > try loading Gem before loading libdir. > i don't know anything about libdir. for clarity: when i use the same Vanilla 47.0 and the same Gem lib in a virtual box (VMware player) with Windows XP everything works like it should. i get a splash-screen, can create a gem-window. rolf

1 1

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list May 2016