hi
sorry for poor email title, is there an object that receives bangs and spits them sequencially to different outputs?
a bit like a counter plus a select 0 1 2 ... but it would take an argument that sets the number of outputs
it might well be that it exists and I am failing to find it...
thanks
enrike
you could use cyclone/cycle for something like that
2017-10-13 6:27 GMT-03:00 Jean-Marie Adrien jm.adrien.mnt@gmail.com:
IOhannes m zmölnig wrote:
that's an interesting issue in general:
i guess the quest for a "single object" to perform a specific task stems from the idea that a c-compiled external is better/faster/less CPU-expensive etc. than a self-made abstraction.
is this even true for PD ?
(a long time ago i heard that this was true for MAX, but never quite figured out why)
or does it depend on the complexity/size of the task ?
would be great to hear an expert's opinion on that, as i often find myself caught in the same thinking (looking for externals instead of patching an abstraction), maybe totally unnecessary ...
thanks for all insights !
oliver
I am no expert, but go the other route: I try to avoid externals like the plague and try to solve everything with abstractions where possible. It will make my patches run in ten years on all operating systems (I hope). Unless I notice a performance problem...
if you use an external to do something simple like this, you are a muppet.
There's also the point and case of just being convenient and being "right there"...
meaning that "by an external", the idea is "one external from the pd extended libraries we have", which, let's face it, is how most people got to know Pd.
2017-10-13 13:52 GMT-03:00 oliver oliver@klingt.org:
from the idea that a c-compiled external is better/faster/less CPU-expensive etc. than a self-made abstraction.
generally that's true but in most cases it doesn't matter that much, especially for control objects since they rarely are the bottleneck of your patch. also there's a saying: "premature optimization is the root of all evil".
however, there are times where it can really matter, mostly in the signal domain. if you have lots of primitive signal objects (like [*~], [+~] etc.) what happens is that for each operation on a signal vector you call a perform routine and loop over all samples (again and again). if you can put everything inside one big loop, the C compiler has a chance to optimize quite a lot. sometimes the external version would only need half the CPU or less, but your mileage may vary. only do it if you need to squeeze as much performance out of your patch as possible - and profile first!
Christof
or., 2017.eko urrren 13a 17:13(e)an, IOhannes m zmölnig igorleak idatzi zuen:
sorry I did not provide any context and I guess it is difficult to understand why would anyone want to do such a trivial thing.
I am doing *very* short introductions to PD to art students who are very far from being technical. In that context I noticed that the less connections the better. I basically provide them with ready to use examples and a basic understanding of how to tweak them.
I could have created a simple abstraction encapsulating the structure but since the number of outputs must be dynamically created on load I am not sure about how to do it. I also thought it might be already something out there, I did not want to reinvent the wheel
enrike
On 10/16/2017 01:49 PM, enrike wrote:
the dynamic part can be solved easily, by splitting the functionality into two parts: a counter (for which you can provide an pre-made abstraction to your students), and a dispatcher (which is a simple [route 0 1 2 3 ...])
so your students would need to create two objects instead of one (with a single connection between the two).
[bang( | [counter 5] | [route 0 1 2 3 4] | | | | |
this should be doable (from a pedagogical pov).
this also has the added bonus that you can easily exchange the simple counting with higher maths, like [random 5].
gdsaf IOhannes
Le 16/10/2017 à 13:49, enrike a écrit :
I am doing *very* short introductions to PD to art students who are very far from being technical. In that context I noticed that the less connections the better. I basically provide them with ready to use examples and a basic understanding of how to tweak them.
I don't blame anyone having trouble to creating box and connecting them, but I think pd is not the right tools for someone in this situation. there are lot's of tools and programming language available...
My point of view is that pd is not simple. You should not lie to your student saying it's simple. They will drop pd when they realize the truth. Teaching the vanilla way is, imo, the best way to teach pd.
In your situation, i'll made everything as subpatch, and sub sub patch: if you look at the surface, you see only the algorithm and few connections. If you go deeper, you can understand how things are made, and how 2 or 3 object can create a counter.
Also, since all student will have different version of pd installed on there computer, the vanilla way it the only one that will work for all. And learning to make clean and well organized code is also very important : it's easier to debug, to understand etc.
cheers c
Le 16/10/2017 à 17:03, cyrille henry a écrit :
... and to read your own patch 3 days later ! ;)
With my experience in teaching Pd, I can confirm what Cyrille wrote :
platforms using compatible version of Pd.
as functions/objects to organize things.
You can find recommandations on the web to write a 'good/nice' code and what you need for this. Learning a programming language is not easy, I don't know who proclaims this ? ++
Jack
nothing I have checked so far does fulfil the requirements here. thats why I introduce to PD, but I not teach PD. I just point them into the tool and allow them to know the basic functions. If anyone wants to learn it I point into vanilla and the tutorials. I would love to be able to properly teach them, but it is impossible given the student's background, the context and the time limits
if you have some suggestion about some tool to replace PD please let me know.
thanks
enrike