Re: [PD] [PD-announce] PPP : pure-data (libpd) based jamming system

[Berenger Recoules]

2016-01-08 7:59 GMT+01:00 Dan Wilcox :

> With PdParty, you can forward the sensor events over OSC to Pd running in
> your computer. I believe people did this with netsend in the RjDj days.
>

Yes ! definitely, we need to add sensor support in ppp, and we probably
want a common api.


>
> Also, I decided to support RjDj apps because: 1 it wasn't that hard to & 2
> there are a lot of grerat scenes I’d like to see working in the future.
>

Same here, but I thought it was a bit harder and needed a bit of thinking
beforehand. Do you support everything ?

[r_#accelerate] : I guess yes :)

[r_#compass], [r_#gyro], [r_#loc], [r_#time], [r_#touch]

and do you provide support for [rj_image] ? (we could probably add this - I
remember making a small spacecraft game with this)

and what about the specific rj externals ? ([rj_accum],
[rj_barflux_accum~], [rj_centroid~], [rj_senergy~], [rj_zcr~]) ?



>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
> On Jan 7, 2016, at 11:47 AM, Berenger Recoules <
> berenger.recou...@gmail.com> wrote:
>
> I think touch is needed for a touchscreen ... so we kept it (but how to
> prototype a multi-touch app in pd-vanilla ?) , and taplist is a good way to
> select an element in list with a very small on screen size so it's pretty
> usefull so we kept it too.
>
>
>


-- 
http://b2renger.github.io/
http://berengerrecoules.wordpress.com/
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] PPP : pure-data (libpd) based jamming system

[Joe White]

Wow, it's pretty amazing to read you all still supporting RjDj stuff! Rock
on!

On 8 January 2016 at 09:28, Berenger Recoules 
wrote:

>
>
> 2016-01-08 7:59 GMT+01:00 Dan Wilcox :
>
>> With PdParty, you can forward the sensor events over OSC to Pd running in
>> your computer. I believe people did this with netsend in the RjDj days.
>>
>
> Yes ! definitely, we need to add sensor support in ppp, and we probably
> want a common api.
>
>
>>
>> Also, I decided to support RjDj apps because: 1 it wasn't that hard to &
>> 2 there are a lot of grerat scenes I’d like to see working in the future.
>>
>
> Same here, but I thought it was a bit harder and needed a bit of thinking
> beforehand. Do you support everything ?
>
> [r_#accelerate] : I guess yes :)
>
> [r_#compass], [r_#gyro], [r_#loc], [r_#time], [r_#touch]
>
> and do you provide support for [rj_image] ? (we could probably add this -
> I remember making a small spacecraft game with this)
>
> and what about the specific rj externals ? ([rj_accum],
> [rj_barflux_accum~], [rj_centroid~], [rj_senergy~], [rj_zcr~]) ?
>
>
>
>>
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com
>> robotcowboy.com
>>
>> On Jan 7, 2016, at 11:47 AM, Berenger Recoules <
>> berenger.recou...@gmail.com> wrote:
>>
>> I think touch is needed for a touchscreen ... so we kept it (but how to
>> prototype a multi-touch app in pd-vanilla ?) , and taplist is a good way to
>> select an element in list with a very small on screen size so it's pretty
>> usefull so we kept it too.
>>
>>
>>
>
>
> --
> http://b2renger.github.io/
> http://berengerrecoules.wordpress.com/
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Create own error message that's findable?

[IOhannes m zmölnig]

On 01/08/2016 05:46 PM, Jonathan Wilkes via Pd-list wrote:
> Pd doesn't have an internal object that can do that.
> But the pd_error function is in m_pd.h.  That means someone can easily 
> make an external [error] that takes an incoming pd message and outputs it as 
> a pd error.  Doing so would print a trackable error to the console that 
> tracks 
> back to the relevant [error] object that generated the error.
> There is probably already an object that does that in the big pile of 
> Pd-extended 
> externals.

a couple:
the "log" library has an [error] object, which does exactly this.

i find this a bit inconvenient because the "find last error" will get
you to the [error] object itself, rather than to the object that
actually threw the error (the abstraction wherein the [error] was
generated).

therefore, iemguts' [canvaserror] will mark an upstream canvas as the
trackable object, so the user is lead to the (imo) "correct" object.

gfmadsr
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] FM matrix with feedback

[Matt Barber]

[rpole~] can be a good option depending on the kind of flexibility you
need. Why the distaste for [block~] size of 1 if it works?

Do you have some pseudocode or a block diagram? That would make it easier
to give advice.

On Fri, Jan 8, 2016 at 11:53 AM, David Medine  wrote:

> This is not for the faint of heart (it is poorly organized and not
> documented at all), and there is no build environment set up for OSX or
> Windows, but I wrote a C language API that I rolled into a Pd extern which
> takes compiled C files that describe feedback networks with approximately 0
> time delay. This is done by modeling the network with dynamical systems and
> solving numerically. I gave a talk about this at ICMC this year.
>
> Using these tools I made a program that runs in Pd that has two
> oscillators that can frequency modulate and sync one another and
> themselves. It maintains the 64 sample block size and the CPU load is
> minimal. It can easily be extended to N oscillators.
>
> I can send a copy of the paper to you directly if you are interested (I
> don't want to hit the whole list with a pdf). Here is the project on github
> -- please forgive my many sins, this is not yet ready for release and it
> shows. https://github.com/dmedine/timelab
> -David
>
>
> On 01/08/2016 03:00 AM, i go bananas wrote:
>
> > If you want shorter feedbacks than 64 samples within a patch, there is
> no way around reducing block size
>
> i still have this itching doubt in that.  i think what we're looking for
> is some real leap of imagination here.
> we are fine with having a block or 2 latency,,,so i'm imagining maybe
> there's some far out hack involving synchronised tabread~'s and delayed
> osc~'s, or something like that,  which would somehow do it.
>
> >You may be able to optimize by
> putting only the very necessary (for the feedback loop) objects into the
> re-blocked subpatch.
>
> yeah that seems the most likely approach now.
>
> >if cpu is a limit, i guess the only solution is to create an external.
>
> this is probably the 2nd most likely solution.
>
> thanks guys for your ideas and help.
>
> On Fri, Jan 8, 2016 at 7:34 PM, Roman Haefeli  wrote:
>
>> If you want shorter feedbacks than 64 samples within a patch, there is
>> no way around reducing block size. You may be able to optimize by
>> putting only the very necessary (for the feedback loop) objects into the
>> re-blocked subpatch.
>>
>> Then there are some classes that do internal sample-size feedbacks,
>> like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be
>> even more expensive than a subpatch with blocksize=1 (at least that's
>> what I remember when I compared two implementations, but  this
>> observation might have been specific to that kind of problem).
>>
>> Roman
>>
>> On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
>> > Hi all, hope everyone's well.
>> >
>> > We're trying to implement a 4-op FM matrix with feedback, copying a
>> > patch my friend made in reaktor using a block size of 1 (sorry, don't
>> > know the full details of that, but he says he can get 1 sample delay
>> > for the feedback)
>> >
>> > Has anyone ever succeeded doing something like this in pd?  I know
>> > about the order forcing using subpatches like in G.05.execution.order
>> > help patch, but that doesn't seem like it will work here, as we still
>> > get DSP loop errors when trying to connect the output of one osc~ back
>> > into the frequency input of the others.
>> >
>> > I'm really looking for a solution that doesn't involve using blocksize
>> > of 1, and anyway, even doing that, still seems the only way to do
>> > feedback without getting DSP loop errors is with s~ / r~ pairs, which
>> > seem to only work at blocksize of 64 anyway?
>> >
>> >
>> > I don't mind adding a bit of latency to the whole system if there's
>> > maybe a hack to do this with tables or something,,,but am really stuck
>> > here wondering what to do.
>> >
>> > any ideas?
>> >
>> >
>> > cheers, Matt
>> > ___
>> > Pd-list@lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> 
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> 
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 

Re: [PD] New "native" Pd GUI support in MobMuPlat

[Dan Wilcox]

Also, if you’re using the PdParty PdParser class, I fixed a bug that was 
causing invalid sendnames: 
https://github.com/danomatika/PdParty/blob/master/src/classes/PdParser.m#L88


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Jan 8, 2016, at 10:20 AM, Dan Wilcox  wrote:
> 
> Ah ok. I just quickly looked at the link you sent. I can change Gui so it 
> only loads the vanilla UIs by default and move the scene-specific stuff into 
> the Scene class, for instance.
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
>> On Jan 8, 2016, at 10:18 AM, Daniel Iglesia > > wrote:
>> 
>> I am using submodules for the PDParty objects for all GUI classes. The only 
>> copy-paste was Gui.h/m, which I changed significantly...
>> 
>> On Fri, Jan 8, 2016 at 8:52 AM, Dan Wilcox > > wrote:
>> 
>>> On Jan 8, 2016, at 9:29 AM, Daniel Iglesia >> > wrote:
>>> 
>>> I'm glad you asked! It's done in a slightly convoluted, potentially 
>>> fragile, possibly un-scalable way.
>>> 
>>> When a user loads a .pd file, pre-proccessing is done on the .pd text to 
>>> generate _two_ new .pd files, one for execution, and one for display The 
>>> two communicate with each other. 
>> 
>> I thought it might be done that way. Does sound knife-edge :) I think it’s 
>> not too conceptually difficult to work with send-receives, plus it makes it 
>> easier to stream data from the device int Pd on your laptop while 
>> developing. 
>> 
>> We could work out a way to make the PdParty objects more extensible so you 
>> could use the iem implementations as well. This can be included with 
>> separating the PdParty UI from the Core and pd gui implementations. SO 
>> Submodule instead of copy/paste classes (I could use any bug finding help as 
>> well!)
>> 
>>> Separate questions for everyone: 
>>> 1) you may notice that the current version does not render connection 
>>> lines. While the patch text lists all the connections (and inlet/outlet 
>>> indices for them), the app doesn't know how many inlets/outlets each object 
>>> has. I haven't delved too deeply for it yet, but is there an interface 
>>> somewhere that will return that information? e.g. here's an atom line for 
>>> an object and its parameters, tell me how many inlets/outlets. If so, then 
>>> connection lines could be rendered correctly. (Without it, I could still 
>>> render conneciton lines, but if there are empty inlets/outlets after a 
>>> connection then they would not be shown.)
>> 
>> I stayed away from connection lines mainly because trying to implement 
>> “editing” is perhaps an unreasonable task for a single, unpaid developer. 
>> Drawing the lines brings that expectation, no? ALso, since I’m using 
>> sends/receievs there are no lines to render anyway ...
>> 
>>> 2) Is showing the full set of patch objects (and, eventually, connection 
>>> lines) even desirable? (Rather than just rendering the gui objects). I'm 
>>> thinking of an option that would switch their display on/off. (But leave 
>>> GUI objects, including message boxes)
>> 
>> Mmm that implies, as I’ve written above, that people can “edit” in MobMuPlat.
>> 
>>> Thanks for input, Dan I.
>>> 
>>> On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox >> > wrote:
>>> How are you doing this?
>>> 
>>> 
>>> Dan Wilcox
>>> @danomatika 
>>> danomatika.com 
>>> robotcowboy.com 
 On Jan 7, 2016, at 9:19 AM, pd-list-requ...@lists.iem.at 
  wrote:
 
 - Unlike PdParty/PdDroidParty, you don't need to define send/receive 
 values for every GUI object. Just drop in your PureData patch, with normal 
 object connections, and it should work. (send/receive communication should 
 also still work as well).
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Create own error message that's findable?

[Matt Barber]

The log library has just such an [error].

On Fri, Jan 8, 2016 at 11:51 AM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> Well, I guess it's the function _prototype_ that's in m_pd.h, to be
> precise...
>
> -Jonathan
>
>
> On Friday, January 8, 2016 11:47 AM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
>
> Pd doesn't have an internal object that can do that.
>
> But the pd_error function is in m_pd.h.  That means someone can easily
> make an external [error] that takes an incoming pd message and outputs it
> as
> a pd error.  Doing so would print a trackable error to the console that
> tracks
> back to the relevant [error] object that generated the error.
>
> There is probably already an object that does that in the big pile of
> Pd-extended
> externals.
>
> -Jonathan
>
>
> On Friday, January 8, 2016 5:38 AM, JF via Pd-list 
> wrote:
>
>
> Hi all,
>
> I'm creating patches that print error messages to the console.
>
> Is it possible to send a special error message that would be trackable by
> Pd's 'Find>Find last error' command?
>
> Many thanks in advance,
> John.
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Create own error message that's findable?

[JF via Pd-list]

Thanks Iohannes and Jonathan!


On Fri, 8/1/16, JF  wrote:

 Subject: Create own error message that's findable?
 To: "pd list" 
 Cc: "Me" 
 Date: Friday, 8 January, 2016, 10:12
 
 Hi all,
 
 I'm creating patches that print error messages to the
 console.
 
 Is it possible to send a special error message that would be
 trackable by Pd's 'Find>Find last error' command?
 
 Many thanks in advance,
 John.
 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Crash of Pd using Gem

[Jack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Executing a patch, I get a crash of Pd.
My configuration:
Ubuntu 12.04
Pd 0.45.5
Gem 0.93 compiled jun 30 2013

For information : with Pd 0.46.5 and GEM: ver: 0.93.git 60998f6, I
only get a freeze on an other system (ubuntu 15.10), so it is
impossible to get a backtrace (maybe with a redirection that i never do)
.


Here the backtrace with Pd 0.45.5 and Gem 0.93 compiled jun 30 2013 on
Ubuntu 12.04 :

verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0
verbose(3): [gemframebuffer]: size: 1235x695
verbose(3): [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0
GL: invalid operation
verbose(3): [gemframebuffer]: size: 1340x753
verbose(3): [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0
verbose(3): [gemframebuffer]: size: 1340x753
verbose(3): [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0
GL: out of memory
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
GL: invalid framebuffer operation
verbose(3): [gemframebuffer]: size: 1328x747
verbose(3): [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0
verbose(3): [gemframebuffer]: size: 1328x747
verbose(3): [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0
GL: out of memory
verbose(3): [gemframebuffer]: size: 1316x740
verbose(3): [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0

Re: [PD] Crash of Pd using Gem

[Jack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To be clear, i am not sure that it is related to Gem, but I use mainly
Gem in my patch, and i don't know what is :
"in list_prepend_list ()" from gdb
++

Jack



Le 08/01/2016 12:13, Jack a écrit :
> Hello,
> 
> Executing a patch, I get a crash of Pd. My configuration: Ubuntu
> 12.04 Pd 0.45.5 Gem 0.93 compiled jun 30 2013
> 
> For information : with Pd 0.46.5 and GEM: ver: 0.93.git 60998f6, I 
> only get a freeze on an other system (ubuntu 15.10), so it is 
> impossible to get a backtrace (maybe with a redirection that i
> never do) .
> 
> 
> Here the backtrace with Pd 0.45.5 and Gem 0.93 compiled jun 30 2013
> on Ubuntu 12.04 :
> 
> verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837] 
> verbose(3): [gemframebuffer]: type: BYTE [5121] verbose(3):
> [gemframebuffer]: texunit: 0 verbose(3): [gemframebuffer]: size:
> 1235x695 verbose(3): [gemframebuffer]: rectangle: 1 ->
> RECTANGLE(ARB) verbose(3): [gemframebuffer]: format: RGB/RGB32
> [6407/34837] verbose(3): [gemframebuffer]: type: BYTE [5121] 
> verbose(3): [gemframebuffer]: texunit: 0 GL: invalid operation 
> verbose(3): [gemframebuffer]: size: 1340x753 verbose(3):
> [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB) verbose(3):
> [gemframebuffer]: format: RGB/RGB32 [6407/34837] verbose(3):
> [gemframebuffer]: type: BYTE [5121] verbose(3): [gemframebuffer]:
> texunit: 0 verbose(3): [gemframebuffer]: size: 1340x753 verbose(3):
> [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB) verbose(3):
> [gemframebuffer]: format: RGB/RGB32 [6407/34837] verbose(3):
> [gemframebuffer]: type: BYTE [5121] verbose(3): [gemframebuffer]:
> texunit: 0 GL: out of memory GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation GL: invalid framebuffer operation GL:
> invalid framebuffer operation verbose(3): [gemframebuffer]: size:
> 1328x747 verbose(3): [gemframebuffer]: rectangle: 1 ->
> RECTANGLE(ARB) verbose(3): [gemframebuffer]: format: RGB/RGB32
> [6407/34837] verbose(3): [gemframebuffer]: type: BYTE [5121] 
> verbose(3): [gemframebuffer]: texunit: 0 verbose(3):
> [gemframebuffer]: size: 1328x747 verbose(3): [gemframebuffer]:
> rectangle: 1 -> RECTANGLE(ARB) verbose(3): [gemframebuffer]:
> format: RGB/RGB32 [6407/34837] 

Re: [PD] Crash of Pd using Gem

[cyrille henry]

there is a "GL: out of memory" in your backtrace.

so i guess a framebuffer can not be created, and gem is not immune to that.
even if gem should not crash, there is no way your patch will work as expected 
in this condition.

cheers
c


Le 08/01/2016 12:22, Jack a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To be clear, i am not sure that it is related to Gem, but I use mainly
Gem in my patch, and i don't know what is :
"in list_prepend_list ()" from gdb
++

Jack



Le 08/01/2016 12:13, Jack a écrit :

Hello,

Executing a patch, I get a crash of Pd. My configuration: Ubuntu
12.04 Pd 0.45.5 Gem 0.93 compiled jun 30 2013

For information : with Pd 0.46.5 and GEM: ver: 0.93.git 60998f6, I
only get a freeze on an other system (ubuntu 15.10), so it is
impossible to get a backtrace (maybe with a redirection that i
never do) .


Here the backtrace with Pd 0.45.5 and Gem 0.93 compiled jun 30 2013
on Ubuntu 12.04 :

verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121] verbose(3):
[gemframebuffer]: texunit: 0 verbose(3): [gemframebuffer]: size:
1235x695 verbose(3): [gemframebuffer]: rectangle: 1 ->
RECTANGLE(ARB) verbose(3): [gemframebuffer]: format: RGB/RGB32
[6407/34837] verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0 GL: invalid operation
verbose(3): [gemframebuffer]: size: 1340x753 verbose(3):
[gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB) verbose(3):
[gemframebuffer]: format: RGB/RGB32 [6407/34837] verbose(3):
[gemframebuffer]: type: BYTE [5121] verbose(3): [gemframebuffer]:
texunit: 0 verbose(3): [gemframebuffer]: size: 1340x753 verbose(3):
[gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB) verbose(3):
[gemframebuffer]: format: RGB/RGB32 [6407/34837] verbose(3):
[gemframebuffer]: type: BYTE [5121] verbose(3): [gemframebuffer]:
texunit: 0 GL: out of memory GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation verbose(3): [gemframebuffer]: size:
1328x747 verbose(3): [gemframebuffer]: rectangle: 1 ->
RECTANGLE(ARB) verbose(3): [gemframebuffer]: format: RGB/RGB32
[6407/34837] verbose(3): [gemframebuffer]: type: BYTE [5121]
verbose(3): [gemframebuffer]: texunit: 0 verbose(3):
[gemframebuffer]: size: 1328x747 verbose(3): 

Re: [PD] [pix_data] - convert rgb values to pd canvas format

[João Pais]

Thanks for your help. Here is the resulting patch, pix2canvas. Sooner or
later it will join the other abstractions in the jmmmp library.

Best,

Joao

2016-01-01 13:10 GMT+01:00 Roman Haefeli :

>
> On Thu, 2015-12-31 at 18:01 +0100, João Pais wrote:
> > If understandable, I send this patch so that it's possible to see what
> > I'm doing.
> >
> >
> > The idea is actually to convert a pix into a bunch of canvases, pixel
> > per pixel - so that a "picture" can be shown on vanilla. Follow the
> > instructions in the patch, and everything should be clear.
> > The conversion is done in [pd RGB]. There are 2 versions, but they
> > have the same output.
>
> There are quite a few different color encodings around in Pd world. For
> the iemguis, there is a difference in encoding between sending a 'color'
> message and defining a color as creation argument. What you've done
> works well for sending 'color' messages to canvas, but not as a creation
> argument. If you want to define a color as creation argument, you have
> to encode it differently, namely as 6bit-per-channel value. So, instead
> of multiplying by 255 and powers of 256, you need to multiply by 63 and
> powers of 64. See attached patch.
>
> I guess the reason is a limitation in how Pd displays (and saves)
> numbers. Although 32-bit float numbers can fully represent 24bit integer
> numbers, numbers are saved with less precision in pd files (and text
> files), since they are truncated to 6 digits. This limitation is
> worked-around by reducing the resolution to 6 bits per channel. The
> highest number (the one representing white) is -262144. It does not
> exceed 6 digits and can be stored at full precision.
>
> Roman
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
#N canvas 191 7 438 666 10;
#X obj 13 245 gemhead;
#X obj 63 285 pix_draw;
#X obj 53 265 pix_image;
#X obj 63 185 bng 15 250 50 0 empty empty empty 0 -6 0 8 -204786 -1
-1;
#X obj 63 205 openpanel;
#X obj 63 225 list prepend open;
#X obj 63 245 list trim;
#X obj 63 305 pix_info . . . .;
#X obj 38 542 pix_data;
#X obj 38 442 f+ 0;
#X obj 38 482 /;
#X obj 38 422 until;
#X obj 21 362 f;
#X obj 157 422 f+ 0;
#X obj 147 482 /;
#X obj 125 422 - 1;
#X obj 147 462 moses;
#X obj 147 502 t b f;
#X obj 21 382 t b f b f;
#X obj 38 502 t b f;
#N canvas 8 115 344 182 pixx 0;
#X restore 373 205 pd pixx;
#X obj 70 642 s pd-pixx;
#X obj 70 592 pack f f f;
#X obj 157 442 t f f;
#X obj 38 462 t f f;
#X msg 321 562 vis 0 \, clear;
#N canvas 687 323 309 283 rgb2iemcreate 0;
#X obj 17 37 inlet;
#X obj 17 87 * 63;
#X obj 51 87 * 63;
#X obj 86 86 * 63;
#X obj 17 107 << 6;
#X obj 17 127 +;
#X obj 17 147 << 6;
#X obj 17 167 +;
#X obj 17 187 * -1;
#X obj 17 207 - 1;
#X obj 17 257 outlet;
#X obj 17 57 unpack f f f f;
#X obj 17 237 spigot;
#X text 67 237 Pixels with alpha = 0 are left out.;
#X text 17 17 Generates color number. Made by Roman Haefeli.;
#X connect 0 0 11 0;
#X connect 1 0 4 0;
#X connect 2 0 5 1;
#X connect 3 0 7 1;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;
#X connect 9 0 12 0;
#X connect 11 0 1 0;
#X connect 11 1 2 0;
#X connect 11 2 3 0;
#X connect 11 3 12 1;
#X connect 12 0 10 0;
#X restore 60 562 pd rgb2iemcreate;
#N canvas 1291 441 254 228 gemwindow 0;
#X obj 20 36 route load;
#X obj 20 56 route success;
#X obj 20 76 bang;
#X msg 20 146 destroy \, dimen 100 100 \, create \, 1;
#X obj 20 196 gemwin 1;
#X obj 20 16 inlet;
#X obj 30 176 inlet;
#X obj 30 96 del 100;
#X obj 30 116 outlet;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 2 0 7 0;
#X connect 3 0 4 0;
#X connect 5 0 0 0;
#X connect 6 0 4 0;
#X connect 7 0 8 0;
#X restore 130 285 pd gemwindow;
#X msg 199 265 destroy;
#X obj 130 362 t b b b b;
#X msg 130 382 vis 1;
#X obj 160 342 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 98 482 + 20;
#X obj 184 562 expr 20 + $f2 - $f1;
#X msg 70 612 obj \$2 \$3 cnv 1 1 1 \$2x\$3 \$2x\$3-i empty 0 0 0 10
\$1 22 0 \;;
#X obj 72 442 - 1;
#X text 13 91 A display innacuracy makes the pixels in the top row
and right column too thick.;
#X text 83 184 Load a file \, and check the subpatch pixx for the result.
;
#X text 12 151 (C) João Pais - jmmmp...@gmail.com;
#X text 13 51 This makes it possible to "import" images into vanilla.
Small pictures are converted fast \, but medium and big files can take
some time to convert and display.;
#X text 13 11 This patch converts images into groups of canvases with
thickness of 1x1 \, pixel per pixel. Invisible pixels (with alpha =
0) are ignored.;
#X text 13 121 Each canvas (i.e. pixel) has its a send and receive
name based on the coordinate: "XxY" and "XxY-i" respectively.;
#X connect 0 0 2 0;
#X connect 2 0 1 0;
#X connect 2 0 7 0;
#X connect 2 0 8 1;
#X connect 2 1 27 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X 

[PD] Window Functions

[Matt Barber]

Hi list, quick DSP question.

In I02.Hann.window.pd there is a Hann window computed by running an [osc~]
for one cycle over 512 samples. Doing it this way is simple but it means
that it doesn't taper all the way to 0 on the right (the next value of the
oscillator after writing the table is 0). I don't know why I hadn't thought
of this before, but is this asymmetry mathematically optimal for windowing
of a single frame? What about in an overlap-add context? I'm trying to
understand the logic, so I'm not too worried about whether it makes a
practical difference. A period of 511 samples would be symmetric and
0-valued at both ends, but there would be no "middle" value at unity.

What's the best way to think of this?

Matt
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Create own error message that's findable?

[JF via Pd-list]

Hi all,

I'm creating patches that print error messages to the console.

Is it possible to send a special error message that would be trackable by Pd's 
'Find>Find last error' command?

Many thanks in advance,
John.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] FM matrix with feedback

[cyrille henry]

Le 08/01/2016 11:16, i go bananas a écrit :

i just tried upsampling, but it seems to hit the cpu harder than lowering 
blocksize, even.

my thought was : blocksize 1 AND upsampling (to improve audio quality)

upsampling a 64 block size is not interesting (in therm of cpu and quality)




and yeah, my friend just got a patch going using delwrite~ and vd~, which we 
can use at blocksize of 1, and it works...  but the hit on the cpu is harsh.

really looking for some way to do this at normal 64 sample blocksize at normal 
samplerate


if cpu is a limit, i guess the only solution is to create an external.
cheers
c



On Fri, Jan 8, 2016 at 7:03 PM, cyrille henry > wrote:

oh, I forget to say that you can also upsample the subpatch in order to 
reduce the feedback latency.



Le 08/01/2016 10:54, cyrille henry a écrit :

s~ and r~ only work with 64 sample block, so you can't use them in this 
situation.
but you can replace them using delwrite~ and delread~ with no delay, 
and force order to write before you read.

cheers
c

Le 08/01/2016 10:42, i go bananas a écrit :

Hi all, hope everyone's well.

We're trying to implement a 4-op FM matrix with feedback, copying a 
patch my friend made in reaktor using a block size of 1 (sorry, don't know the 
full details of that, but he says he can get 1 sample delay for the feedback)

Has anyone ever succeeded doing something like this in pd?  I know 
about the order forcing using subpatches like in G.05.execution.order help 
patch, but that doesn't seem like it will work here, as we still get DSP loop 
errors when trying to connect the output of one osc~ back into the frequency 
input of the others.

I'm really looking for a solution that doesn't involve using 
blocksize of 1, and anyway, even doing that, still seems the only way to do 
feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to 
only work at blocksize of 64 anyway?

I don't mind adding a bit of latency to the whole system if there's 
maybe a hack to do this with tables or something,,,but am really stuck here 
wondering what to do.

any ideas?

cheers, Matt


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] FM matrix with feedback

[Roman Haefeli]

If you want shorter feedbacks than 64 samples within a patch, there is
no way around reducing block size. You may be able to optimize by
putting only the very necessary (for the feedback loop) objects into the
re-blocked subpatch.

Then there are some classes that do internal sample-size feedbacks,
like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be
even more expensive than a subpatch with blocksize=1 (at least that's
what I remember when I compared two implementations, but  this
observation might have been specific to that kind of problem).

Roman
 
On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
> Hi all, hope everyone's well. 
> 
> We're trying to implement a 4-op FM matrix with feedback, copying a
> patch my friend made in reaktor using a block size of 1 (sorry, don't
> know the full details of that, but he says he can get 1 sample delay
> for the feedback)
> 
> Has anyone ever succeeded doing something like this in pd?  I know
> about the order forcing using subpatches like in G.05.execution.order
> help patch, but that doesn't seem like it will work here, as we still
> get DSP loop errors when trying to connect the output of one osc~ back
> into the frequency input of the others. 
> 
> I'm really looking for a solution that doesn't involve using blocksize
> of 1, and anyway, even doing that, still seems the only way to do
> feedback without getting DSP loop errors is with s~ / r~ pairs, which
> seem to only work at blocksize of 64 anyway?
> 
> 
> I don't mind adding a bit of latency to the whole system if there's
> maybe a hack to do this with tables or something,,,but am really stuck
> here wondering what to do.  
> 
> any ideas?  
> 
> 
> cheers, Matt
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] FM matrix with feedback

[i go bananas]

Hi all, hope everyone's well.

We're trying to implement a 4-op FM matrix with feedback, copying a patch
my friend made in reaktor using a block size of 1 (sorry, don't know the
full details of that, but he says he can get 1 sample delay for the
feedback)

Has anyone ever succeeded doing something like this in pd?  I know about
the order forcing using subpatches like in G.05.execution.order help patch,
but that doesn't seem like it will work here, as we still get DSP loop
errors when trying to connect the output of one osc~ back into the
frequency input of the others.

I'm really looking for a solution that doesn't involve using blocksize of
1, and anyway, even doing that, still seems the only way to do feedback
without getting DSP loop errors is with s~ / r~ pairs, which seem to only
work at blocksize of 64 anyway?

I don't mind adding a bit of latency to the whole system if there's maybe a
hack to do this with tables or something,,,but am really stuck here
wondering what to do.

any ideas?

cheers, Matt
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] FM matrix with feedback

[cyrille henry]

s~ and r~ only work with 64 sample block, so you can't use them in this 
situation.
but you can replace them using delwrite~ and delread~ with no delay, and force 
order to write before you read.

cheers
c

Le 08/01/2016 10:42, i go bananas a écrit :

Hi all, hope everyone's well.

We're trying to implement a 4-op FM matrix with feedback, copying a patch my 
friend made in reaktor using a block size of 1 (sorry, don't know the full 
details of that, but he says he can get 1 sample delay for the feedback)

Has anyone ever succeeded doing something like this in pd?  I know about the 
order forcing using subpatches like in G.05.execution.order help patch, but 
that doesn't seem like it will work here, as we still get DSP loop errors when 
trying to connect the output of one osc~ back into the frequency input of the 
others.

I'm really looking for a solution that doesn't involve using blocksize of 1, 
and anyway, even doing that, still seems the only way to do feedback without 
getting DSP loop errors is with s~ / r~ pairs, which seem to only work at 
blocksize of 64 anyway?

I don't mind adding a bit of latency to the whole system if there's maybe a 
hack to do this with tables or something,,,but am really stuck here wondering 
what to do.

any ideas?

cheers, Matt


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] FM matrix with feedback

[cyrille henry]

oh, I forget to say that you can also upsample the subpatch in order to reduce 
the feedback latency.


Le 08/01/2016 10:54, cyrille henry a écrit :

s~ and r~ only work with 64 sample block, so you can't use them in this 
situation.
but you can replace them using delwrite~ and delread~ with no delay, and force 
order to write before you read.

cheers
c

Le 08/01/2016 10:42, i go bananas a écrit :

Hi all, hope everyone's well.

We're trying to implement a 4-op FM matrix with feedback, copying a patch my 
friend made in reaktor using a block size of 1 (sorry, don't know the full 
details of that, but he says he can get 1 sample delay for the feedback)

Has anyone ever succeeded doing something like this in pd?  I know about the 
order forcing using subpatches like in G.05.execution.order help patch, but 
that doesn't seem like it will work here, as we still get DSP loop errors when 
trying to connect the output of one osc~ back into the frequency input of the 
others.

I'm really looking for a solution that doesn't involve using blocksize of 1, 
and anyway, even doing that, still seems the only way to do feedback without 
getting DSP loop errors is with s~ / r~ pairs, which seem to only work at 
blocksize of 64 anyway?

I don't mind adding a bit of latency to the whole system if there's maybe a 
hack to do this with tables or something,,,but am really stuck here wondering 
what to do.

any ideas?

cheers, Matt


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] FM matrix with feedback

[i go bananas]

i just tried upsampling, but it seems to hit the cpu harder than lowering
blocksize, even.

and yeah, my friend just got a patch going using delwrite~ and vd~, which
we can use at blocksize of 1, and it works...  but the hit on the cpu is
harsh.

really looking for some way to do this at normal 64 sample blocksize at
normal samplerate

On Fri, Jan 8, 2016 at 7:03 PM, cyrille henry  wrote:

> oh, I forget to say that you can also upsample the subpatch in order to
> reduce the feedback latency.
>
>
>
> Le 08/01/2016 10:54, cyrille henry a écrit :
>
>> s~ and r~ only work with 64 sample block, so you can't use them in this
>> situation.
>> but you can replace them using delwrite~ and delread~ with no delay, and
>> force order to write before you read.
>>
>> cheers
>> c
>>
>> Le 08/01/2016 10:42, i go bananas a écrit :
>>
>>> Hi all, hope everyone's well.
>>>
>>> We're trying to implement a 4-op FM matrix with feedback, copying a
>>> patch my friend made in reaktor using a block size of 1 (sorry, don't know
>>> the full details of that, but he says he can get 1 sample delay for the
>>> feedback)
>>>
>>> Has anyone ever succeeded doing something like this in pd?  I know about
>>> the order forcing using subpatches like in G.05.execution.order help patch,
>>> but that doesn't seem like it will work here, as we still get DSP loop
>>> errors when trying to connect the output of one osc~ back into the
>>> frequency input of the others.
>>>
>>> I'm really looking for a solution that doesn't involve using blocksize
>>> of 1, and anyway, even doing that, still seems the only way to do feedback
>>> without getting DSP loop errors is with s~ / r~ pairs, which seem to only
>>> work at blocksize of 64 anyway?
>>>
>>> I don't mind adding a bit of latency to the whole system if there's
>>> maybe a hack to do this with tables or something,,,but am really stuck here
>>> wondering what to do.
>>>
>>> any ideas?
>>>
>>> cheers, Matt
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] FM matrix with feedback

[William Huston]

You may want to look at Martin Brinkmann's patch Chaosmonster1.

http://www.martin-brinkmann.de/pd-patches.html

I studied it about a year ago, and gave up trying to understand how it
works. But it makes fantastic noises.

Martin says it "generates noise- and 'chaos'-sounds with six oscillators
with mutual frequency, filter and ringmodulation. Some similarities
to the famous 'heishere' reaktor ensemble by lazyfish."



On Friday, January 8, 2016, i go bananas  wrote:
> Hi all, hope everyone's well.
>
> We're trying to implement a 4-op FM matrix with feedback, copying a patch
my friend made in reaktor using a block size of 1 (sorry, don't know the
full details of that, but he says he can get 1 sample delay for the
feedback)
>
> Has anyone ever succeeded doing something like this in pd?  I know about
the order forcing using subpatches like in G.05.execution.order help patch,
but that doesn't seem like it will work here, as we still get DSP loop
errors when trying to connect the output of one osc~ back into the
frequency input of the others.
>
> I'm really looking for a solution that doesn't involve using blocksize of
1, and anyway, even doing that, still seems the only way to do feedback
without getting DSP loop errors is with s~ / r~ pairs, which seem to only
work at blocksize of 64 anyway?
> I don't mind adding a bit of latency to the whole system if there's maybe
a hack to do this with tables or something,,,but am really stuck here
wondering what to do.
>
> any ideas?
> cheers, Matt

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Crash of Pd using Gem

[Jack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Cyrille,

Thanx for your answer.
I guess I have the part of my patch where there is the problem (i
disable the gemhead and there is no more crash). It is attached...
++

Jack



Le 08/01/2016 12:32, cyrille henry a écrit :
> there is a "GL: out of memory" in your backtrace.
> 
> so i guess a framebuffer can not be created, and gem is not immune
> to that. even if gem should not crash, there is no way your patch
> will work as expected in this condition.
> 
> cheers c
> 
> 
> Le 08/01/2016 12:22, Jack a écrit : To be clear, i am not sure that
> it is related to Gem, but I use mainly Gem in my patch, and i don't
> know what is : "in list_prepend_list ()" from gdb ++
> 
> Jack
> 
> 
> 
> Le 08/01/2016 12:13, Jack a écrit :
 Hello,
 
 Executing a patch, I get a crash of Pd. My configuration:
 Ubuntu 12.04 Pd 0.45.5 Gem 0.93 compiled jun 30 2013
 
 For information : with Pd 0.46.5 and GEM: ver: 0.93.git
 60998f6, I only get a freeze on an other system (ubuntu
 15.10), so it is impossible to get a backtrace (maybe with a
 redirection that i never do) .
 
 
 Here the backtrace with Pd 0.45.5 and Gem 0.93 compiled jun
 30 2013 on Ubuntu 12.04 :
 
 verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837] 
 verbose(3): [gemframebuffer]: type: BYTE [5121] verbose(3): 
 [gemframebuffer]: texunit: 0 verbose(3): [gemframebuffer]:
 size: 1235x695 verbose(3): [gemframebuffer]: rectangle: 1 -> 
 RECTANGLE(ARB) verbose(3): [gemframebuffer]: format:
 RGB/RGB32 [6407/34837] verbose(3): [gemframebuffer]: type:
 BYTE [5121] verbose(3): [gemframebuffer]: texunit: 0 GL:
 invalid operation verbose(3): [gemframebuffer]: size:
 1340x753 verbose(3): [gemframebuffer]: rectangle: 1 ->
 RECTANGLE(ARB) verbose(3): [gemframebuffer]: format:
 RGB/RGB32 [6407/34837] verbose(3): [gemframebuffer]: type:
 BYTE [5121] verbose(3): [gemframebuffer]: texunit: 0
 verbose(3): [gemframebuffer]: size: 1340x753 verbose(3): 
 [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB) verbose(3): 
 [gemframebuffer]: format: RGB/RGB32 [6407/34837] verbose(3): 
 [gemframebuffer]: type: BYTE [5121] verbose(3):
 [gemframebuffer]: texunit: 0 GL: out of memory GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL: 
 invalid framebuffer operation GL: invalid framebuffer
 operation GL: invalid framebuffer operation GL: invalid
 framebuffer operation GL: invalid framebuffer operation GL:
 invalid 

Re: [PD] Crash of Pd using Gem

[cyrille henry]

array: couldn't find named array 'lettres'

did you try it alone?

did you try to reduce all framebuffer size in order to reduce memory usage?
c


Le 08/01/2016 14:26, Jack a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Cyrille,

Thanx for your answer.
I guess I have the part of my patch where there is the problem (i
disable the gemhead and there is no more crash). It is attached...
++

Jack



Le 08/01/2016 12:32, cyrille henry a écrit :

there is a "GL: out of memory" in your backtrace.

so i guess a framebuffer can not be created, and gem is not immune
to that. even if gem should not crash, there is no way your patch
will work as expected in this condition.

cheers c


Le 08/01/2016 12:22, Jack a écrit : To be clear, i am not sure that
it is related to Gem, but I use mainly Gem in my patch, and i don't
know what is : "in list_prepend_list ()" from gdb ++

Jack



Le 08/01/2016 12:13, Jack a écrit :

Hello,

Executing a patch, I get a crash of Pd. My configuration:
Ubuntu 12.04 Pd 0.45.5 Gem 0.93 compiled jun 30 2013

For information : with Pd 0.46.5 and GEM: ver: 0.93.git
60998f6, I only get a freeze on an other system (ubuntu
15.10), so it is impossible to get a backtrace (maybe with a
redirection that i never do) .


Here the backtrace with Pd 0.45.5 and Gem 0.93 compiled jun
30 2013 on Ubuntu 12.04 :

verbose(3): [gemframebuffer]: format: RGB/RGB32 [6407/34837]
verbose(3): [gemframebuffer]: type: BYTE [5121] verbose(3):
[gemframebuffer]: texunit: 0 verbose(3): [gemframebuffer]:
size: 1235x695 verbose(3): [gemframebuffer]: rectangle: 1 ->
RECTANGLE(ARB) verbose(3): [gemframebuffer]: format:
RGB/RGB32 [6407/34837] verbose(3): [gemframebuffer]: type:
BYTE [5121] verbose(3): [gemframebuffer]: texunit: 0 GL:
invalid operation verbose(3): [gemframebuffer]: size:
1340x753 verbose(3): [gemframebuffer]: rectangle: 1 ->
RECTANGLE(ARB) verbose(3): [gemframebuffer]: format:
RGB/RGB32 [6407/34837] verbose(3): [gemframebuffer]: type:
BYTE [5121] verbose(3): [gemframebuffer]: texunit: 0
verbose(3): [gemframebuffer]: size: 1340x753 verbose(3):
[gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB) verbose(3):
[gemframebuffer]: format: RGB/RGB32 [6407/34837] verbose(3):
[gemframebuffer]: type: BYTE [5121] verbose(3):
[gemframebuffer]: texunit: 0 GL: out of memory GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: invalid framebuffer operation GL: invalid
framebuffer operation GL: invalid framebuffer operation GL:
invalid framebuffer operation GL: invalid framebuffer
operation GL: 

Re: [PD] Crash of Pd using Gem

[Jack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 08/01/2016 14:34, cyrille henry a écrit :
> array: couldn't find named array 'lettres'

Yep, I just copy/paste the part causing problem.

> 
> did you try it alone?

Not yet. I have to finish this patch today.
I will send a "working" bug patch this evening.

> 
> did you try to reduce all framebuffer size in order to reduce
> memory usage?

Not yet too.
I will try after my work ;)
++

Jack


> c
> 
> 
> Le 08/01/2016 14:26, Jack a écrit : Hi Cyrille,
> 
> Thanx for your answer. I guess I have the part of my patch where
> there is the problem (i disable the gemhead and there is no more
> crash). It is attached... ++
> 
> Jack
> 
> 
> 
> Le 08/01/2016 12:32, cyrille henry a écrit :
 there is a "GL: out of memory" in your backtrace.
 
 so i guess a framebuffer can not be created, and gem is not
 immune to that. even if gem should not crash, there is no way
 your patch will work as expected in this condition.
 
 cheers c
 
 
 Le 08/01/2016 12:22, Jack a écrit : To be clear, i am not
 sure that it is related to Gem, but I use mainly Gem in my
 patch, and i don't know what is : "in list_prepend_list ()"
 from gdb ++
 
 Jack
 
 
 
 Le 08/01/2016 12:13, Jack a écrit :
>>> Hello,
>>> 
>>> Executing a patch, I get a crash of Pd. My
>>> configuration: Ubuntu 12.04 Pd 0.45.5 Gem 0.93 compiled
>>> jun 30 2013
>>> 
>>> For information : with Pd 0.46.5 and GEM: ver:
>>> 0.93.git 60998f6, I only get a freeze on an other
>>> system (ubuntu 15.10), so it is impossible to get a
>>> backtrace (maybe with a redirection that i never do) .
>>> 
>>> 
>>> Here the backtrace with Pd 0.45.5 and Gem 0.93 compiled
>>> jun 30 2013 on Ubuntu 12.04 :
>>> 
>>> verbose(3): [gemframebuffer]: format: RGB/RGB32
>>> [6407/34837] verbose(3): [gemframebuffer]: type: BYTE
>>> [5121] verbose(3): [gemframebuffer]: texunit: 0
>>> verbose(3): [gemframebuffer]: size: 1235x695
>>> verbose(3): [gemframebuffer]: rectangle: 1 -> 
>>> RECTANGLE(ARB) verbose(3): [gemframebuffer]: format: 
>>> RGB/RGB32 [6407/34837] verbose(3): [gemframebuffer]:
>>> type: BYTE [5121] verbose(3): [gemframebuffer]:
>>> texunit: 0 GL: invalid operation verbose(3):
>>> [gemframebuffer]: size: 1340x753 verbose(3):
>>> [gemframebuffer]: rectangle: 1 -> RECTANGLE(ARB)
>>> verbose(3): [gemframebuffer]: format: RGB/RGB32
>>> [6407/34837] verbose(3): [gemframebuffer]: type: BYTE
>>> [5121] verbose(3): [gemframebuffer]: texunit: 0 
>>> verbose(3): [gemframebuffer]: size: 1340x753
>>> verbose(3): [gemframebuffer]: rectangle: 1 ->
>>> RECTANGLE(ARB) verbose(3): [gemframebuffer]: format:
>>> RGB/RGB32 [6407/34837] verbose(3): [gemframebuffer]:
>>> type: BYTE [5121] verbose(3): [gemframebuffer]:
>>> texunit: 0 GL: out of memory GL: invalid framebuffer
>>> operation GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid 
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid 
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid 
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid
>>> framebuffer operation GL: invalid framebuffer operation
>>> GL: invalid framebuffer operation GL: invalid 
>>> framebuffer operation GL: invalid framebuffer 

Re: [PD] New "native" Pd GUI support in MobMuPlat

[Daniel Iglesia]

I'm glad you asked! It's done in a slightly convoluted, potentially
fragile, possibly un-scalable way.

When a user loads a .pd file, pre-proccessing is done on the .pd text to
generate _two_ new .pd files, one for execution, and one for display The
two communicate with each other.
This split is done at:
https://github.com/monkeyswarm/MobMuPlat/blob/master/MobMuPlat-iOS/MobMuPlat/PdGui/MMPPdPatchDisplayUtils.m#L16

1) The "engine" patch is the patch that is actually opened by libpd and
generates audio. The processing replaces each gui object with a Pd
abstraction I made (termed a "shim" in the code) that has a send/receive
relationship (with an auto-generated handle) with the MobMuPlat- layer GUI
code.
So a line (this is the toggle in the "MMPExamples-NativeGUI.pd" file).
#X obj 253 440 tgl 45 0 /demoToggleSend /demoToggleReceive
I'm_using_send_and_receive
becomes
#X obj 253 440 MMPPdGuiFiles/MMPPdGuiShim 15-gui-send 15-gui-rec
/demoToggleSend /demoToggleReceive;
"15-gui-send" and "15-gui-receive" are the handles for send/receive with
the user-visible gui object.
Note that existing send/receive behavior is kept intact (with
/demoToggleSend and /demoToggleReceive)
There's a few flavors of this shim (in
github.com/monkeyswarm/MobMuPlat/tree/master/MobMuPlat-iOS/MobMuPlat/PdGui):
a main one for most GUI objects, a special one for a "bang", and a special
one for a message object.

2) The "GUI" patch is a simpler process, it just, for every GUI object,
sets the send/receive handles to the same auto-generated handles generated
for the matching "engine" shim that should communicate with it. After
processing, this pd patch is then read and rendered to native-app-layer GUI
widgets.

I've tested this to work for using the "internal" (object property)
send/receive labels, attaching to send/receive objects, using "set",
one-to-many and many-to-one communication. However there's probably some
use case I've overlooked (or some fun way to make it stack overflow when it
shouldn't). Let me know...!

Separate questions for everyone:
1) you may notice that the current version does not render connection
lines. While the patch text lists all the connections (and inlet/outlet
indices for them), the app doesn't know how many inlets/outlets each object
has. I haven't delved too deeply for it yet, but is there an interface
somewhere that will return that information? e.g. here's an atom line for
an object and its parameters, tell me how many inlets/outlets. If so, then
connection lines could be rendered correctly. (Without it, I could still
render conneciton lines, but if there are empty inlets/outlets after a
connection then they would not be shown.)

2) Is showing the full set of patch objects (and, eventually, connection
lines) even desirable? (Rather than just rendering the gui objects). I'm
thinking of an option that would switch their display on/off. (But leave
GUI objects, including message boxes)

Thanks for input, Dan I.


On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox  wrote:

> How are you doing this?
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
> On Jan 7, 2016, at 9:19 AM, pd-list-requ...@lists.iem.at wrote:
>
> - Unlike PdParty/PdDroidParty, you don't need to define send/receive
> values for every GUI object. Just drop in your PureData patch, with normal
> object connections, and it should work. (send/receive communication should
> also still work as well).
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] New "native" Pd GUI support in MobMuPlat

[Dan Wilcox]

Ah ok. I just quickly looked at the link you sent. I can change Gui so it only 
loads the vanilla UIs by default and move the scene-specific stuff into the 
Scene class, for instance.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Jan 8, 2016, at 10:18 AM, Daniel Iglesia  wrote:
> 
> I am using submodules for the PDParty objects for all GUI classes. The only 
> copy-paste was Gui.h/m, which I changed significantly...
> 
> On Fri, Jan 8, 2016 at 8:52 AM, Dan Wilcox  > wrote:
> 
>> On Jan 8, 2016, at 9:29 AM, Daniel Iglesia > > wrote:
>> 
>> I'm glad you asked! It's done in a slightly convoluted, potentially fragile, 
>> possibly un-scalable way.
>> 
>> When a user loads a .pd file, pre-proccessing is done on the .pd text to 
>> generate _two_ new .pd files, one for execution, and one for display The two 
>> communicate with each other. 
> 
> I thought it might be done that way. Does sound knife-edge :) I think it’s 
> not too conceptually difficult to work with send-receives, plus it makes it 
> easier to stream data from the device int Pd on your laptop while developing. 
> 
> We could work out a way to make the PdParty objects more extensible so you 
> could use the iem implementations as well. This can be included with 
> separating the PdParty UI from the Core and pd gui implementations. SO 
> Submodule instead of copy/paste classes (I could use any bug finding help as 
> well!)
> 
>> Separate questions for everyone: 
>> 1) you may notice that the current version does not render connection lines. 
>> While the patch text lists all the connections (and inlet/outlet indices for 
>> them), the app doesn't know how many inlets/outlets each object has. I 
>> haven't delved too deeply for it yet, but is there an interface somewhere 
>> that will return that information? e.g. here's an atom line for an object 
>> and its parameters, tell me how many inlets/outlets. If so, then connection 
>> lines could be rendered correctly. (Without it, I could still render 
>> conneciton lines, but if there are empty inlets/outlets after a connection 
>> then they would not be shown.)
> 
> I stayed away from connection lines mainly because trying to implement 
> “editing” is perhaps an unreasonable task for a single, unpaid developer. 
> Drawing the lines brings that expectation, no? ALso, since I’m using 
> sends/receievs there are no lines to render anyway ...
> 
>> 2) Is showing the full set of patch objects (and, eventually, connection 
>> lines) even desirable? (Rather than just rendering the gui objects). I'm 
>> thinking of an option that would switch their display on/off. (But leave GUI 
>> objects, including message boxes)
> 
> Mmm that implies, as I’ve written above, that people can “edit” in MobMuPlat.
> 
>> Thanks for input, Dan I.
>> 
>> On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox > > wrote:
>> How are you doing this?
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>>> On Jan 7, 2016, at 9:19 AM, pd-list-requ...@lists.iem.at 
>>>  wrote:
>>> 
>>> - Unlike PdParty/PdDroidParty, you don't need to define send/receive values 
>>> for every GUI object. Just drop in your PureData patch, with normal object 
>>> connections, and it should work. (send/receive communication should also 
>>> still work as well).
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] animation api

[Jonathan Wilkes via Pd-list]

Try changing GUI_BYTESPERPING back to its original value.
-Jonathan
 

On Thursday, January 7, 2016 12:21 PM, Ivica Ico Bukvic  wrote:
 

  I would test the same patch you built. To tax tkpath and tk in particular you 
can spread toggles to the four corners of the screen since redrawing area 
calculation on those toolkits is fairly inefficient. CPU spec and CPU overhead 
data would also help figure out where the bottleneck lies. e.g. my experience 
is from a low-powered AMD APU (essentially AMD's Atom counterpart).
 
 On 1/7/2016 11:52 AM, Jonathan Wilkes wrote:
  
  Do you have a simple patch to test? 
  Not sure exactly what's going on, but I can think of three relevant areas: * 
node.js APIs are largely built to be asynchronous * V8 javascript engine does 
JIT compilation of hot code * Chromium goes out of its way to ensure that 
nothing blocks the renderer from doing its job 
 Of course advertisers don't have to pay for the CPU they consume on your 
device, which 
  mean all browser-based technology are CPU hogs. 
  -Jonathan
  
  
  
  
  
  
   
 
  On Thursday, January 7, 2016 11:19 AM, Ivica Ico Bukvic  
wrote:
  
 
Would you please test the same on pd-l2ork and/or vanilla? If there is a 
stark difference, this may suggest that node webkit does some kind of internal 
event pruning (which would be really sweet). Also, checking CPU overhead may 
help shed some light as to what is going on. Finally, what are the specs of 
your machine?
 
  On 1/7/2016 2:20 AM, Jonathan Wilkes wrote:
  
 In the GUI port I hooked up about 14 toggles to a [metro 1] and was 
getting 
  anywhere between 30 and 40 fps in the GUI.  I could continue creating new 
  objects in the same patch. 
  Now if I connected each of those toggles to a [print] I'd probably freeze the 
  GUI.  But I'm not doing any optimization on console, nor limiting the 
  size of the scrollback buffer.  (I am, however, displaying a hit count beside 
  duplicate messages which cuts down immensely on noise.) 
  At least for now, if some common patch behavior is able to DOS the 
  GUI I'd rather have it freeze up as an incentive to fix the underlying 
problem. 
  -Jonathan
  
  
  
 On Wednesday, January 6, 2016 1:07 PM, Ivica Bukvic  
wrote:
  
 
Create a metronome with less than 2 milliseconds clock and connect it to a 
bunch  of toggles, turn it on, and enjoy interacting with a barely responsive 
gui. The same is achievable with a less dubious implementation where a 
graphical  user interface simply has a lot of concurrently animated components. 
NB: depending on your computer specs the two millisecond threshold may have  to 
be set lower. -- 
 Ivica Ico Bukvic, D.M.A.
 Associate Professor
 Computer Music
 ICAT Senior Fellow
 Director -- DISIS, L2Ork
 Virginia Tech
 School of Performing Arts – 0141
 Blacksburg, VA 24061
 (540) 231-6139
 i...@vt.edu
 www.performingarts.vt.edu
 disis.icat.vt.edu
 l2ork.icat.vt.edu
 ico.bukvic.net 
 
   On Jan 6, 2016 9:31 AM, "Jonathan Wilkes"  wrote:
 
Are there more than two people (matju  and Miller) who understand the 
  _current_ design? 
  -Jonathan
  
  On Wednesday, January 6,  2016 12:00 AM, Ivica Ico Bukvic 
 wrote:
  
 
The following is going somewhat  OT but nonetheless based on this  very 
interesting  topic: application framerate is  no more deterministic than the 
proposed idea. Just because  monitor refreshes at 60Hz doesn't  mean the app 
will do the  same or consistently. Yet, pegging  GUI updates at 60Hz (think  
speedlim-like behavior) despite all  the loose ends will undoubtedly provide 
improved  responsiveness over a GUI where one can  send sub-millisecond  change 
requests, most of which will  never see the light of the day, despite eating up 
tons of CPU and in  all likelihood bringing it down to its knees.
 
  On 1/4/2016 9:32 PM, Jonathan  Wilkes wrote:
  
Having an animation method allows  GUI-side optimizations that aren't 
  possible when the animation is  smeared across the socket/parser/eval'er. 
  Determinism: GUI rendering isn't  deterministic, at least not in the way Pd's 
  scheduler is.  For example, how could the GUI  (tcl/tk or otherwise) even 
  know that it missed a deadline?
  
  I guess the simple API I'm toying  with is "stretching the accordion"  so to 
  speak, and potentially  showing the cracks more explicitly  with a longer 
  running animation than can currently  be seen in Pd's GUI.  But that can be 
  remedied, either by recursively  halving a single animation into  smaller 
ones, 
  or just giving up and using  [line].
  
  The greater benefit is  that more elegant types of visual  feedback become 
  possible without being discarded out  of hand due to their potential for 
  audio interruption. 
  -Jonathan
  
  On Monday, January 4,  2016 5:20 PM, Ivica Ico Bukvic  
wrote:
  
 
On 1/3/2016 3:24 PM, Jonathan  Wilkes 

Re: [PD] Create own error message that's findable?

[Jonathan Wilkes via Pd-list]

Pd doesn't have an internal object that can do that.
But the pd_error function is in m_pd.h.  That means someone can easily 
make an external [error] that takes an incoming pd message and outputs it as 
a pd error.  Doing so would print a trackable error to the console that tracks 
back to the relevant [error] object that generated the error.
There is probably already an object that does that in the big pile of 
Pd-extended 
externals.

-Jonathan
  

On Friday, January 8, 2016 5:38 AM, JF via Pd-list  
wrote:
 

 Hi all,

I'm creating patches that print error messages to the console.

Is it possible to send a special error message that would be trackable by Pd's 
'Find>Find last error' command?

Many thanks in advance,
John.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] PPP : pure-data (libpd) based jamming system

[Dan Wilcox]

AT this point, I wish I stuck to just the vanilla gui implementations as adding 
the droidparty & rjdj support is one of the reasons PdParty wasn’t released 
years ago. That plus me basically doing a PhD amount of work while in an MFA, 
I’m still playing catch up!

> 2016-01-08 7:59 GMT+01:00 Dan Wilcox  >:
> With PdParty, you can forward the sensor events over OSC to Pd running in 
> your computer. I believe people did this with netsend in the RjDj days.
> 
> Yes ! definitely, we need to add sensor support in ppp, and we probably want 
> a common api.
>  
> Also, I decided to support RjDj apps because: 1 it wasn't that hard to & 2 
> there are a lot of grerat scenes I’d like to see working in the future.
> 
> Same here, but I thought it was a bit harder and needed a bit of thinking 
> beforehand. Do you support everything ?
> 
> [r_#accelerate] : I guess yes :)

Most things, except for scene paging. See 
https://github.com/danomatika/PdParty/blob/master/doc/PdParty_User_Guide.md#rjdj-compatibility
 


> [r_#compass], [r_#gyro], [r_#loc], [r_#time], [r_#touch]

I have all those sensors implemented, just not all those specific messages I 
realize now. I could the missing ones (#compass and #loc) in about 10 minutes 
as I have basically the same thing implemented with diff names and possible 
different arguments (#heading and #loc). Does anyone member the specifics? I 
have the last RjDj dev bundle with the example scenes to work from, but I don’t 
remember coming across any of those, just #touch and #time.

> and do you provide support for [rj_image] ? (we could probably add this - I 
> remember making a small spacecraft game with this)

Yup, both rj_image and rj_text. I basically borrowed the pd-for-android 
ScenePlayer  
algorithms.

> and what about the specific rj externals ? ([rj_accum], [rj_barflux_accum~], 
> [rj_centroid~], [rj_senergy~], [rj_zcr~]) ?


Those are available from the rjlib repo 
(https://github.com/rjdj/rjlib/tree/master/src), including the “deprecated” 
abstractions. 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list