Re: [PD] How's Pd limited?

Or if [fexpr~] is too expensive... On Mon, Mar 14, 2016 at 12:00 AM, Chris McCormick wrote: > On 25/02/16 22:39, i go bananas wrote: > >> real-time zero-crossing detection with sample-rate precision. >>> >> >> if (incomingSignal > 0 && previousIncomingSignal < 0 ||

Re: [PD] How's Pd limited?

On 25/02/16 22:39, i go bananas wrote: real-time zero-crossing detection with sample-rate precision. if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0 || previousIncomingSignal > 0) return 1; else return 0; fexpr~ if (($x1[0] > 0 && $x1[-1] < 0) || ($x1[0] < 0 &&

Re: [PD] How's Pd limited?

Thanks for clarification. I made a mistake too MOD = MOS dhurr On 7 March 2016 at 14:12, Billy Stiltner wrote: > > > I see a mistake in my previous post. > I used the term "Well Formed" in the wrong way. > > MOS = Well Formed > EDO or equal division MOS have generator

Re: [PD] How's Pd limited?

I see a mistake in my previous post. I used the term "Well Formed" in the wrong way. MOS = Well Formed EDO or equal division MOS have generator and period that are coprime. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

Re: [PD] How's Pd limited?

Hi Billy, Have to admit much of that went over my limited skillset. However, the MOD stuff is composition magic. Thanks for sharing, Julian On 2 March 2016 at 13:55, Billy Stiltner wrote: > My struggles with it are not really limitations of pd. > It's the way I have

Re: [PD] How's Pd limited?

My struggles with it are not really limitations of pd. It's the way I have went about modelling a polyphonic synthesizer and using the tcl controls as MVC then making the controls a part of the preset machine. Everything is available for me to break the view away from the DSP its just that there

Re: [PD] How's Pd limited?

For me Pd is totally outstanding, even more with the Cleveland/Cincinnati spaghetti reports. The Gui is ok, perhaps more than ok, as it is. When you are patching you always change things, and the final visual effect is irrelevant. Also straight cables (or unsegmented) are clear to follow. This

Re: [PD] How's Pd limited?

I also feel more limited than Pd. 2016-02-25 22:14 GMT+01:00 Matt Barber : > > > On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner > wrote: > >> >> this is a trick question >> pd is not limited, it is the most object oriented c code you will ever >>

Re: [PD] How's Pd limited?

Spaghetti is more of a Cincinnati thing. http://www.skylinechili.com/ways.php On Thu, Feb 25, 2016 at 4:42 PM, Jonathan Wilkes wrote: > > It's always Cleveland. > > You'd probably work like the dickens and make a patch that saves > Cleveland. But the next day when they

Re: [PD] How's Pd limited?

I see what's happening the fb receive is sending the same number over and over for the whole 64 block when subtracting from the count input, we get a block that goes from 1 to 64. snapshot is giving me the first value (1), your magic glass is giving you the last (64). And I just acted too soon

Re: [PD] How's Pd limited?

> It's always Cleveland. You'd probably work like the dickens and make a patch that saves Cleveland.  But the next day when they attack another city you'd open up the patch and be unable to make sense of all your spaghetti. At least you could use your Cleveland-saving patch as a prototype to

Re: [PD] How's Pd limited?

On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner wrote: > > this is a trick question > pd is not limited, it is the most object oriented c code you will ever see > in the entire universe. > with some practice you can learn how to model high level polymorphic > virtual

Re: [PD] How's Pd limited?

this is a trick question pd is not limited, it is the most object oriented c code you will ever see in the entire universe. with some practice you can learn how to model high level polymorphic virtual destructors. ___ Pd-list@lists.iem.at mailing list

Re: [PD] How's Pd limited?

On 25/02/16 20:45, Alexandre Torres Porres wrote: > well, I was able to replicate my test with count... > > not sure what's happening, but that's it, a one sample delay in feedback, > for what it seems it looks as if cyclone/snapshot~ does not work like it should. when i turn on "magic glass" it

Re: [PD] How's Pd limited?

well, I was able to replicate my test with count... not sure what's happening, but that's it, a one sample delay in feedback, for what it seems I gotta go into my dentist now, whish me luck 2016-02-25 16:38 GMT-03:00 Alexandre Torres Porres : > > would be great if it

Re: [PD] How's Pd limited?

> would be great if it worked. (i've tried similar tricks...) yeah, don't know what happened, when I tried with count~ it seemed to work, for my own surprise, I wasn;t expecting it to work either. Now I have no idea what happened. I may have also just gone insane for good :) 2016-02-25 14:52

Re: [PD] How's Pd limited?

BTW, this is germane to some work that I have been doing and it just so happens that I have a figure handy. In the figure are the spectra for two oscillators frequency modulating each other in a tight feedback loop. The first two were made with FM oscillators adapted from Pd's FM example

Re: [PD] How's Pd limited?

On 25/02/16 18:09, Alexandre Torres Porres wrote: > 2016-02-25 13:57 GMT-03:00 martin brinkmann : > >> if you want feedback in a complex patch, >> (like these virtual-virtual-modular-systems) the only thing >> you can do is to reblock everything to 1, which is not always

Re: [PD] How's Pd limited?

I had tested with count~ before and the result was clearly a one sample delay, subtracting the output of count to a feedback line gave me the result of 1. I'll test it again later 2016-02-25 14:38 GMT-03:00 cyrille henry : > > > Le 25/02/2016 18:09, Alexandre Torres Porres a

Re: [PD] How's Pd limited?

Le 25/02/2016 18:09, Alexandre Torres Porres a écrit : 2016-02-25 13:57 GMT-03:00 martin brinkmann >: if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to

Re: [PD] How's Pd limited?

On 25/02/16 02:22, Alexandre Torres Porres wrote: easy have hard synced oscillators phasor~ 100 | *~ 2.666 | wrap~ | dac~ doing it bandlimited so it doesn't sound like poop is a lot harder (you can get part of the way there by oversampling with filtering) Claude -- http://mathr.co.uk

Re: [PD] How's Pd limited?

2016-02-25 13:57 GMT-03:00 martin brinkmann : > if you want feedback in a complex patch, > (like these virtual-virtual-modular-systems) the only thing > you can do is to reblock everything to 1, which is not always possible > (due to high cpu load, conflicting

Re: [PD] How's Pd limited?

2016-02-25 12:47 GMT-03:00 Christof Ressi : > > you could easy have hard synced oscillators, but no... > > yes, you can, with a little trick. See my abstraction (needs zexy). > I have a simple vanilla trick already :) ___

Re: [PD] How's Pd limited?

You don't even need that much logic for zero crossings. They are easy to find using some simple arithmetic. See attached. On Thu, Feb 25, 2016 at 9:39 AM, i go bananas wrote: > >real-time zero-crossing detection with sample-rate precision. > > this is something that is super

Re: [PD] How's Pd limited?

On Thu, Feb 25, 2016 at 4:19 PM, Alexandre Torres Porres wrote: > > 2016-02-25 6:49 GMT-03:00 peiman khosravi : > >> Two example I can think of. One-sample delay/feedback for filter design >> etc. And real-time zero-crossing detection with sample-rate

Re: [PD] How's Pd limited?

>real-time zero-crossing detection with sample-rate precision. this is something that is super simple to implement. it's like: if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0 || previousIncomingSignal > 0) return 1; else return 0; i also don't understand why such an

Re: [PD] How's Pd limited?

2016-02-25 6:49 GMT-03:00 peiman khosravi : > Two example I can think of. One-sample delay/feedback for filter design > etc. And real-time zero-crossing detection with sample-rate precision. you can do that in Pd vanilla with a single object: [fexpr~] like I said, I

Re: [PD] How's Pd limited?

Hey Chris, Here's a vanilla tanh~ version that doesn't involve a table lookup https://github.com/enzienaudio/heavylib/blob/master/hv_tanh.pd Cheers, Joe On 25 February 2016 at 04:03, Chris McCormick wrote: > Hello, > > On 24/02/16 17:23, Alexandros Drymonitis wrote: > >>

Re: [PD] How's Pd limited?

Two example I can think of. One-sample delay/feedback for filter design etc. And real-time zero-crossing detection with sample-rate precision. On Wednesday, February 24, 2016, Matt Barber wrote: > How fine-grained does it need to be? As long as all the parameters are >

Re: [PD] How's Pd limited?

Hello, On 24/02/16 17:23, Alexandros Drymonitis wrote: If you copy the [tanh] abstraction from purepd and make it a signal one, doesn't that work? Then it's vanilla. expr~ is available in all versions of Pd and has the same license. It is probably slower than making a table, so doing what

Re: [PD] How's Pd limited?

2016-02-24 18:54 GMT-03:00 Brian Fay : > The issue with blocking is that you don't have fine-grained control of an > audio, process, right? > there are plenty techniques for having patches running with sample accuracy - problem is that most pd and max objects miss this

Re: [PD] How's Pd limited?

i think there's noyhing in gen that you cant do in pd, it has a small set of objects, but i guess the deal is that it, somehow, makes it more efficient, that's all. i've started studying max/msp recently, and i've found many things lacking in it, more than i would've thought, by the way. cheers

Re: [PD] How's Pd limited?

> It sounds very difficult, but I imagine gen~ does something like that. I don't think the payoff is big enough to justify the development, unless what gets compiled are good old signal and/or control object chains that everybody is already familiar with. That's what happened with Javascript

Re: [PD] How's Pd limited?

…only by your imagination… /Mikael ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

How fine-grained does it need to be? As long as all the parameters are known at the beginning of the block, you have everything you need. As far as human interaction is concerned, 64-sample blocks are extremely fine-grained. The individual cycles of the pitches at the beginning of Beethoven's 5th

Re: [PD] How's Pd limited?

Just poll every microsecond, and increment the counter by one microsecond. If there's something scheduled for that microsecond, do it. :) On Wednesday, February 24, 2016 4:19 PM, Matt Barber wrote: OK, now I'm having trouble even imagining how an unblocked audio

Re: [PD] How's Pd limited?

The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change

Re: [PD] How's Pd limited?

OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context). On Wed, Feb 24, 2016 at 2:58 PM, David Medine wrote: > This doesn't answer Matt's question at all (apologies), but just as a >

Re: [PD] How's Pd limited?

This doesn't answer Matt's question at all (apologies), but just as a clarification, ChucK /does /block audio. It's just that ChucK always blocks at the minimum size of 1 sample per block. 1 is still a block size though, and it still implies the same problems associated with order of

Re: [PD] How's Pd limited?

] How's Pd limited? You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations. www.peimankhosravi.co.uk On 24 February 2016 at 16:15, cyrille henry <c...@chnry.net> wrote: Le

Re: [PD] How's Pd limited?

Are there any other DSP environments besides ChucK that don't block audio? Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] definitely takes a hit, but it's usually possible to minimize how much of the DSP chain is actually blocked at 1. I guess with Csound you can

Re: [PD] How's Pd limited?

You can do this with MSP's poly~ too but I'm guessing that the CPU costs are quite heavy. Moreover, there are operators in gen that are designed for low-level operations. *www.peimankhosravi.co.uk

Re: [PD] How's Pd limited?

I think one of the big limitations is a difficulty in turning "hot" code "cool". For example, suppose the [hungry~] abstraction is at the heart of your patch but it consumes a lot of CPU.  What do you do? Typically the process involves only two steps:1. make esoteric changes that marginally

Re: [PD] How's Pd limited?

Le 24/02/2016 16:50, peiman khosravi a écrit : One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay. you can use [block~ 1 1 1] in a pd subpatch. cheers c P On Tuesday, February 23, 2016, Samuel Burt

Re: [PD] How's Pd limited?

One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay. P On Tuesday, February 23, 2016, Samuel Burt wrote: > David, > > One thing I attempted and couldn't find a solution for was the following, >

Re: [PD] How's Pd limited?

maybe this is also a matter of convenience: i'd rather have the dsp-framework automagically divide and distribute my program to the available resources than to care for it myself. while it is for example ok to put each complex voice of a synth in an extra pd~ to make optimum use of the few cores,

Re: [PD] How's Pd limited?

Hello, Le 24/02/2016 00:19, Matt Barber a écrit : > Can anyone explain more why [pd~] doesn't fulfill the desire for > parallel processing, and maybe provide an example of something outside > of Pd that does? I don't feel like I have a great handle on the design. > As Jonathan said, it seems like

Re: [PD] How's Pd limited?

Thanks for replying, Jonathan. If Pd-l2ork starts to supports Mac I'll seriously consider switching to it. Sounds like many of the issues and inconveniences are fixed there. Let me reply to your questions. > * Standard GUI objects are ugly and have limited functionality. > > Yes. Just curious--

Re: [PD] How's Pd limited?

On Wed, Feb 24, 2016 at 3:48 AM, Chris McCormick wrote: > On 22/02/16 09:49, Matti Viljamaa wrote: > >> How do you think Pure Data is limited? >> > > expr~ tanh($v1) > If you copy the [tanh] abstraction from purepd and make it a signal one, doesn't that work? Then it's

Re: [PD] How's Pd limited?

On 22/02/16 09:49, Matti Viljamaa wrote: How do you think Pure Data is limited? expr~ tanh($v1) I would apologise for being a smart-ass but I don't feel sorry. Cheers, Chris. -- http://mccormick.cx/ ___ Pd-list@lists.iem.at mailing list

Re: [PD] How's Pd limited?

Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear,

Re: [PD] How's Pd limited?

I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very

Re: [PD] How's Pd limited?

O.oSo easy!! Em ter, 23 de fev de 2016 às 07:44, Dan Wilcox escreveu: > Em ter, 23 de fev de 2016 às 00:56, Matt Barber > escreveu: > >> Newest vanilla has basic object resize, which actually helps a lot with >> some of the issues brought up here.

Re: [PD] How's Pd limited?

On 22/02/16 02:49, Matti Viljamaa wrote: > How do you think Pure Data is limited? for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a

Re: [PD] How's Pd limited?

> Align: https://youtu.be/lCIeIelbw74 Looks like there's a whole collection of tools to do that, including a transient bbox with drag hooks. > Route Patch Cords: https://youtu.be/2u_UJQ8OfvUI'm pretty sure Pd-l2ork can > do the first part of that video.  But it can also do a many-to-one >

Re: [PD] How's Pd limited?

If you're using the newest vanilla, the [array] object lets you get a range of a given size from an index onset as a list, and to put the list at an onset of another array. It's faster than I thought it would be. So, you could just load your files sequentially into one table and copy them from

Re: [PD] How's Pd limited?

I guess I've never seen a way to load multiple samples into a single array. That might solve another problem I'm currently sorting out. How do you do that? Sam On Tue, Feb 23, 2016, 1:56 PM Matt Barber wrote: > This is doable, actually, but not easy. [delay] and [vline~]

Re: [PD] How's Pd limited?

> On Feb 23, 2016, at 11:19 AM, pd-list-requ...@lists.iem.at wrote: > > It's an incremental approach, so it still suffers from socket chatter > problems that tcl/tk Pd has. But now that tcl/tk is removed from the C code, > logic is slowly making its way over to the GUI side. I’m hoping to

Re: [PD] How's Pd limited?

This is doable, actually, but not easy. [delay] and [vline~] both have subsample accuracy. It would be substantially easier if you could preprocess and deliver the sequence as one big message dump to [vline~]. If you loaded all of the files into one array (up to about 6:20 of audio at 44100) and

Re: [PD] How's Pd limited?

Does the GUI in pd-l2orc run on a separate core? For all versions of Pd, the GUI runs as a separate process.  It communicates with the Pd process over a TCP socket. -Jonathan On Tuesday, February 23, 2016 1:51 PM, Samuel Burt wrote: David, One thing I

Re: [PD] How's Pd limited?

David, One thing I attempted and couldn't find a solution for was the following, mostly owing to the limitation of interfacing with a 64 sample block size. I wanted to have a directory of hundreds of audio recordings. Each one would be a single wavelength from an interesting sound, like a bass

Re: [PD] How's Pd limited?

But I guess pd-l2ork addresses some of these issues? I know Jonathan has done a lot of work on a node webkit gui for pd: https://github.com/jonwwilkes/pd-nw That's a mirror that I stopped updating awhile back. The repo is here:https://puredata.osuosl.org/ It's an incremental approach, so it still

Re: [PD] How's Pd limited?

> if you like your fancy gui's, use them! Pd's GUI is plain and limited, yes.  But what it lacks in beauty it makes up for in tcp socket chatter. -Jonathan On Tuesday, February 23, 2016 12:02 PM, david medine wrote: One thing I'd be interested in knowing about is

Re: [PD] How's Pd limited?

On Tue, Feb 23, 2016 at 11:27 AM, jamal crawford wrote: if you like your fancy gui's, use them! have you heard of OSC? just dump > whatever you want thru it and run a headless instance of pd, where you > recieve it. nobody will even notice. are you a nerd or just pretending :P

Re: [PD] How's Pd limited?

This thread has inspired me to work on a fork called Pd-limited. On Tue, Feb 23, 2016 at 11:27 AM, jamal crawford wrote: > hi list > > > >Max have features like auto-align horizontally/vertically and align and > route patch cords which is very useful to >organize patch cords

Re: [PD] How's Pd limited?

hi list >Max have features like auto-align horizontally/vertically and align and >route patch cords which is very useful to >organize patch cords and >make the  thinks more readable. I like them a lot. this is so old. this comparing so old. if you like your fancy gui's, use them! have you

Re: [PD] How's Pd limited?

2016-02-23 12:44 GMT-03:00 Roman Haefeli : > In my experience, more often I resize the box accidentally than > willingly. I'd welcome a way to disable this feature. How about "shift + click and drag"? ___ Pd-list@lists.iem.at

Re: [PD] How's Pd limited?

On Tue, 2016-02-23 at 09:30 -0500, Ivica Ico Bukvic wrote: > I forget, does the mouse cursor change when you hover? Last time I > checked in vanilla it didn't but that was a while ago. If not, it may > help make it easier to expose the said feature and aim for the sweet > spot. It becomes a

Re: [PD] How's Pd limited?

> I'd love if Pd would provide some true multi-threading (not like [pd~] which > is tightly coupled to its parent). How would the patch/audio remain determinstic if the units in the dsp graph aren't tightly coupled? -Jonathan On Tuesday, February 23, 2016 9:34 AM, Ivica Ico Bukvic

Re: [PD] How's Pd limited?

I forget, does the mouse cursor change when you hover? Last time I checked in vanilla it didn't but that was a while ago. If not, it may help make it easier to expose the said feature and aim for the sweet spot. On 2/23/2016 5:44 AM, Dan Wilcox wrote: Em ter, 23 de fev de 2016 às 00:56, Matt

Re: [PD] How's Pd limited?

On 2/22/2016 11:40 PM, Jonathan Wilkes via Pd-list wrote: > Max have features like auto-align horizontally/vertically Pd-l2ork has this, too-- "Tidy Up" in the Edit menu. It's a little strange-- if you click it once it will sweep the selected objects into a "pile", and if you click again it

Re: [PD] How's Pd limited?

Hello, keeping track of send/receive is not very difficult, just put a few s/r names in your patches and use a [route] object to your different methods then you can get easier in console what happens in FUDI. Le 22/02/2016 22:57, Peter Nyboer a écrit : I also dislike Send and Receive, but

Re: [PD] How's Pd limited?

Le 23/02/2016 09:00, Roman Haefeli a écrit : going to do when it dies? I'd love if Pd would provide some true multi-threading (not like [pd~] which is tightly coupled to its parent). Roman That's a clever point I'm also sharing, but from informations grabbed in tcl documentation that seem

Re: [PD] How's Pd limited?

> Em ter, 23 de fev de 2016 às 00:56, Matt Barber > escreveu: > Newest vanilla has basic object resize, which actually helps a lot with some > of the issues brought up here. It's also very helpful that comments can be > resized, so you can set

Re: [PD] How's Pd limited?

On 2016-02-23 00:17, Jonathan Wilkes via Pd-list wrote: > [...] +1. 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] How's Pd limited?

On 2016-02-23 02:20, Morten Minothi Kristiansen wrote: > Pd extended > 0.43. as you are undoubtedly aware (it has been stated so many times on ths list), Pd-extended is unmaintained for a couple of years and for all practical issues to be considered dead. please use Pd-vanilla. fgmasdr

Re: [PD] How's Pd limited?

On Mon, 2016-02-22 at 01:19 -0800, Eugene Lazarchik wrote: > Where do I start? Thanks. That is a pretty comprehensive list, though I do not agree with all your points (ugly look, mailing list, big patches become unreadable fast). For me the most important point is still missing. * Since Pure

Re: [PD] How's Pd limited?

My answer is in the form of a Koan: *If an oscillator's output is not connected to a DAC,* *does it still make a sound? * On Sun, Feb 21, 2016 at 8:49 PM, Matti Viljamaa wrote: > Perhaps a bit of broad question, but I find it interesting in order to > speculate about

Re: [PD] How's Pd limited?

I found that: http://forum.pdpatchrepo.info/topic/9749/question-resize-canvas-realtime/4 Em ter, 23 de fev de 2016 às 03:22, Esteban Viveros escreveu: > Em ter, 23 de fev de 2016 às 00:56, Matt Barber > escreveu: > >> Newest vanilla has basic object

Re: [PD] How's Pd limited?

Em ter, 23 de fev de 2016 às 00:56, Matt Barber escreveu: > Newest vanilla has basic object resize, which actually helps a lot with > some of the issues brought up here. It's also very helpful that comments > can be resized, so you can set the wrap point. > > Cool.. I'm

Re: [PD] How's Pd limited?

Like that: Align: https://youtu.be/lCIeIelbw74 Route Patch Cords: https://youtu.be/2u_UJQ8OfvU Em ter, 23 de fev de 2016 às 02:09, Jonathan Wilkes escreveu: > > Here's a radical idea that I've sometimes pondered: what if we could > create left-inlets and right-outlets as

Re: [PD] How's Pd limited?

> Here's a radical idea that I've sometimes pondered: what if we could create >left-inlets and right-outlets as well as the standard top- and bottom- ones?  If the object has more than one inlet or outlet you wouldn't be able to fit them on the side of the object box. Also, you run into a common

Re: [PD] How's Pd limited?

> Max have features like auto-align horizontally/vertically Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little strange-- if you click it once it will sweep the selected objects into a "pile", and if you click again it will fan them out like a deck of cards.  But it can work

Re: [PD] How's Pd limited?

> On Feb 22, 2016, at 8:54 PM, pd-list-requ...@lists.iem.at wrote: > > From: Esteban Viveros <emvive...@gmail.com <mailto:emvive...@gmail.com>> > Subject: Re: [PD] How's Pd limited? > Date: February 22, 2016 at 8:48:16 PM MST > To: Johnny Mauser <joson.andr...@goo

Re: [PD] How's Pd limited?

ka.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Feb 22, 2016, at 6:20 PM, pd-list-requ...@lists.iem.at wrote: > > From: Morten Minothi Kristiansen <mino...@gmail.com > <mailto:mino...@gmail.com>> > Subject: Re: [PD] How's Pd l

Re: [PD] How's Pd limited?

Newest vanilla has basic object resize, which actually helps a lot with some of the issues brought up here. It's also very helpful that comments can be resized, so you can set the wrap point. On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros wrote: > A feature I miss in

Re: [PD] How's Pd limited?

A feature I miss in vanilla and extended (pdl2ork solve that) is resize objects via one point click and drag. If it is hard to implement, a "apply" button on properties can help to design UI's in Vanilla. Max have features like auto-align horizontally/vertically and align and route patch cords

Re: [PD] How's Pd limited?

for extended, I recommend 0.42-5, but ideal is to try vanilla and use the extended libraries you actually need 2016-02-23 0:45 GMT-03:00 Alexandre Torres Porres : > forget about pd extended 0.43, I never recommend it !!! > > 2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen

Re: [PD] How's Pd limited?

forget about pd extended 0.43, I never recommend it !!! 2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen : > Not tried different builds, please giide me. > 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" >: > >> Its been like this with

Re: [PD] How's Pd limited?

That's something i completly experiece diffrently!! Pd fucks up in practise and development quiet often (maybe i make it fuck up) but once it runs, it runs stable every time!! Love to pd, Johnny Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" : > Not tried different

Re: [PD] How's Pd limited?

Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" : > Its been like this with Mavericks, Yosemite and El capitalist. Pd extended > 0.43. I did a clean install a week ago and it worked fine for a week until > I installed live 9.

Re: [PD] How's Pd limited?

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended 0.43. I did a clean install a week ago and it worked fine for a week until I installed live 9. It still worked until it suddenly hit some kond of wall again. Mort 23. feb. 2016 02.15 skrev "AP Vague" :

Re: [PD] How's Pd limited?

Woah, that's definitely a problem I haven't heard of... I'm guessing you've already tried using different builds. What OS are you on? On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen < mino...@gmail.com> wrote: > On my last two comouters PD wont open unless I start it with a

Re: [PD] How's Pd limited?

On my last two comouters PD wont open unless I start it with a standalone patch I made long ago. It works for a little while, then crashes completely and for ever more...unless I use the stand alone. Recently...5 min before a gig the standalone wouldnt even start. The gig was fine as Im nott 100%

Re: [PD] How's Pd limited?

> It's just that the presence of those features makes it much easier not to > care, and many users just don't care, and it makes things worse for those of > us who have to use that patch elsewhere. Short story: I'm not going to write the code to implement segmented cords, and I don't think

Re: [PD] How's Pd limited?

I also dislike Send and Receive, but end up using them in pd. I don’t like that they are hard to keep track of (I see the receive, where’s the send?). I guess $0 does clear up the global issues, but it feels hacky. I managed to get rid of them in Max by relying on the pattr and pattrstorage

Re: [PD] How's Pd limited?

> On Feb 22, 2016, at 2:09 PM, pd-list-requ...@lists.iem.at wrote: > > From: Eugene Lazarchik > > > I consider sends and receives evil. They're similar to global variables or > goto statements in general purpose programming

Re: [PD] How's Pd limited?

> 2016-02-22 17:25 GMT-03:00 Matt Barber >: > I've said this before, but I think there are very good reasons not to ever > include segmented patch cords (although hideable patch cords would be even > worse). These two features are responsible

Re: [PD] How's Pd limited?

Hmm i'd say there's no way to force people to employ transparent, modular software design as long as you want to keep the language (whether it's patcher- or code-based) somewhat flexible and powerful ... On Mon, Feb 22, 2016 at 09:03:16PM +, Jonathan Wilkes via Pd-list wrote: > There are

Re: [PD] How's Pd limited?

I consider sends and receives evil. They're similar to global variables or goto statements in general purpose programming languages. When you see a receive object, it's not obvious where all corresponding sends may be. As opposed to simply following where the cords go. Also, consider a subpatch

  1   2   >