Re: [PD] Controlling amplitude with readsf~
On 22/04/14 21:12, Claire O'Connor wrote: I am still having a bit of trouble. I am using another line object to ramp up the number box to fade in my .wav file but when I go to ramp it back down, it jumps straight to zero. I have also tried to 'reset' the line object but that involves sending a message '0' which makes the amplitude of the .wav file jump down again. Any ideas as to how this issue might be resolved? I have a line of .wav files that I want to fade in and fade out as they each play. sending a single number [0( will jump straight to that value, a pair will ramp so [0 2000( goes from current value to 0 in 2 seconds then [1 3000( goes to 1 in 3 seconds ... play around with the help patch. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] oggread~ not working on pd-extended or libpd on windows.
On 05/04/14 14:21, Martin Peach wrote: I think it's here: http://sourceforge.net/p/pure-data/patches/ that seems to be for pd rather than externals??? maybe a patch to debian package pd-pdogg, which could then get upstream, since for some (especially older) externals this may be the most actively maintained repo? I don't know about [oggread~] in particular though ... but is this problem/patch only a windows one? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Looking for some processing tools for audio mixing
On 01/04/14 00:20, Christoph Kuhr wrote: Hi everyone, at the moment I am using some analog outboard equipment to assist me with my audio mixing. for audio mixing to replace an analogue mixer you are probably better off looking at ardour, or any other digital audio workstation. You can of course mix audio in pd, there are many objects to help you, no need for extended ... the help menu of any pd will show you examples, the documentation (in the help menu) will explain more. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Pd to play sounds simultaneously on 8 speakers with cheap computer
On 29/03/14 22:56, Jack wrote: Hello, Is it possible to use BeagleBoard, Raspberry Pi, Udoo or others without dropout with this configuration : 8 IR sensors 1 BeagleBoard (or Raspberry Pi, or Udoo or others) with Pd and linux 1 sound cards with 8 output 8 speakers like this : 8 IR sensors - Beagleboard - sound card - 8 speakers (so it is possible to play 8 sounds at 44100 Hz 16 bits *simultaneously*). If yes, can you tell me which model of sound card works well with these cards ? Thanx. ++ The esi gigaport hd+ is said to give 8 outs cleanly on an Rpi, search the list for reports from several people, but I have not tried it myself. With an Rpi you might then use the GPIO for your IR, but if the IR stuff is USB then you'd have to test, and may well be out of luck. A cheaper sound card and a more expensive computer may be just as sensible though. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Raspberry Pi Wolfson Audio Card
On 19/03/14 23:27, Winfried Ritsch wrote: Am Mittwoch, 19. März 2014, 00:24:25 schrieb Simon Wise: On 18/03/14 22:02, Winfried Ritsch wrote: Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega: Anyone wants to share their experience with the BeagleBoneBlack? Yes. Since autumn, i am trying to set up an kit hardware+software with BBB for computer-musicians as stomp box, works quite well, after successfully installed it in a long term sound installation (headless): some points short: system: + BBB moved to Debian since this year (good) that is very good to hear! and the rest means they seem a good choice for embedded, the USB implementation on the Pis really is a pain,and means you need to be very selective about what you try to do. it is also not very clean on others, but improved. I have never tested a Pi, which kernel version does you use, since there have been updates on USB since 3.12 a couple of projects last year used usb, but trying several different dongles found ones that worked well enough, so we left it at that. My current project is HDMI only (plus ethernet for setting up only), so I'm not so worried ... they are not here at the moment so can't check, but notes suggest 3.13 probably, I've not updated since last year. I'll upgrade tolatest raspbian when they are back. Simon. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD on Raspbian
On 19/03/14 23:29, Christian Fischer wrote: - When opening a new Pd window (ctrl+n), it pops up so high in the bottom left corner of the screen, that you can not see the menu anymore. Therefore the window is not moveable or usable. Used Pd already on various PCs and OS but this I have never experienced. What can be done? As mentioned already openbox (the default desktop for the Pi) does the usual thing and Alt-drag anywhere on the window should move it where you want. If you are using linux (or Apple) I find connecting to the Pi with ethernet and: ssh -X pi@192.168.1.20 replacing the IP with the actual one of course, it is usually announced on the console at the end of the boot process, then set your laptop ethernet to a compatible manual IP you are set to go. is a very comfortable way to work, the pd windows are then on my laptop and the Pi does not need to run a desktop at all. pcmanfm should get you a file browser window, so you can navigate and open things in the familiar GUI way, if that is what you prefer. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Raspberry Pi Wolfson Audio Card
On 18/03/14 22:02, Winfried Ritsch wrote: Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega: Anyone wants to share their experience with the BeagleBoneBlack? Yes. Since autumn, i am trying to set up an kit hardware+software with BBB for computer-musicians as stomp box, works quite well, after successfully installed it in a long term sound installation (headless): some points short: system: + BBB moved to Debian since this year (good) that is very good to hear! and the rest means they seem a good choice for embedded, the USB implementation on the Pis really is a pain,and means you need to be very selective about what you try to do. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tannhauser Pure Data compiler
On 17/03/14 23:26, Ingo wrote: I just found out about the Tannhäuser Pure Data compiler. Does anybody know who makes it or where to get this compiler? Thanks! Ingo google took me here ... https://www.hackerleague.org/hackathons/automatic-music-hackathon/hacks/tannhauser-a-c-compiler-for-pure-data perhaps Martin Roth is your man https://www.hackerleague.org/users/mhroth ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
Any digital instrument also has latencies. Basically it is a matter of playing the instrument you are using. How are you measuring the latency? with a digital instrument, in this context, it has to be from the time the gesture is made that controls the effect, till the effect is heard by the listener, and separately till the effect is heard by the musician. so the 15 or 20 ms of DSP processing latency is only one part of that... then add such things as input latency (say midi or the audio input circuitry, or the distance from source to microphone ...) output latency (say distance from the reproduced sound source to the ears). then consider the response time involved in detecting the gestures, like in the recent thread here (or LAU?) talking about tracking following notes played on a guitar and using meta data based on that. then consider the difference between judging the effect as heard by a listener compared to what is heard by the musician (re timing in this case, but generally these is a very substantially different sounds in any wood, flesh and metal instruments ... what a singer hears unless they are wearing headsets is very different indeed to what anyone else listening hears) then consider the time between the start of a sound and its main attack, the time read as the timing of the note. as pointed out earlier in the thread much western orchestral music is not tightly timed rhythmically, but there are many other very old musical traditions that are very percussive, with very intricate timings that deal with significant distances between players or with instruments like big gongs or bells that have huge latencies built in. in very many circumstances, now and historically, 20 ms here or there is tiny, as long as it is consistent ... jitter (generally) is unplayable. in the particular circumstance of a musician whose experience is limited to playing with headsets or close monitors getting fed a mix of the final sound sent to the listener ... most of those normal latencies have been bypassed and the digital world has made that kind of performance much, much easier for modern musicians (those playing with that kind of technological assistance) ... then 15 ms can become very significant ... best for them to avoid big gongs, plus any digital effect that requires taking latency into account when playing. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
On 15/03/14 23:03, Dan Wilcox wrote: I guess I don't get that since I've been playing that relative latency for years. How is 10-15 ms not real time? It's not even really perceivable unless you're doing lots of high rate short attack decay stuff. At least as far as I can tell. I must be slow. :D Then again, I might be wrong. I'll probably try the hard float Debian UDOO image next. That might give us some room. Musicians in orchestras have been playing with, dealing with, much longer latencies for centuries. An orchestra cannot all be within a metre or so of each other, they are 10s of metres apart, and that is on top of the different set of differences in distance to the audience. In a pit in an opera or ballet it gets much worse. Any modern PA adds substantial latencies to achieve a good sound in the audience, and mostly use mics and foldback in other kinds of performances, and make the musicians life easier by avoiding the natural latency issues of an acoustic performance. Organ players have dealt with huge latencies for as long as there have been big pipe organs. Percussionists using real instruments don't get the attack from their instruments till well after they initiate the note by starting to move their stick toward the cymbal. Wood and metal instruments all have considerable latencies, some much more than others, it is all part of playing that particular instrument. Electric guitar players rely on the latency between amp and pickup (this time only a few milliseconds) for their sound. Any digital instrument also has latencies. Basically it is a matter of playing the instrument you are using. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using pd live (sans computer/laptop/raspberry pi)
On 15/03/14 09:56, Charles Z Henry wrote: On Fri, Mar 14, 2014 at 4:29 PM, Jonathan Wilkesjancs...@yahoo.com wrote: On 03/14/2014 03:44 PM, Dan Wilcox wrote: Without a computer, no. Without a desktop or laptop computer, yes. Well, maybe we could design and manufacture an enormous ASIC that runs libpd. -Jonathan I appreciate the spirit of that... but man, that would be one intimidating project. oh to have an infinite number of monkeys programming FPGAs ... hence the attraction of building on and adding to open source projects, or falling back on hardware that is at least open, programmable and accessible down to some level. These things are to big to do alone on most scales. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] KMI SoftStep foot controller?
On 09/03/14 02:58, Jonghyun Kim wrote: For OSC connection, you can also [netsend] with tcp, [netsend -u] with udp My experience was [netsend] is a little better than others. Ok ... for me [packOSC] didn't work with [netsend], I didn't investigate why but just used [udpsend] instead. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] KMI SoftStep foot controller?
On 08/03/14 21:13, Alexandros Drymonitis wrote: On Sat, Mar 8, 2014 at 2:18 AM, Simon Wisesimonzw...@gmail.com wrote: On 08/03/14 06:24, Jonghyun Kim wrote: Thanks Chris for the answer! I was worried about compatibility with Pd. How about OSC function with Pd? It's OSC works with [netsend] or [udpsend]? [your OSC message( | [packOSC] | [udpsend] You'll have to explicitly import the mrpeach library, use [import mrpeach] you are right, or use [osc/packOSC] and [iemnet/udpsend] for these ones .. pd-osc: /usr/lib/pd/extra/osc/packOSC.pd_linux pd-iemnet: /usr/lib/pd/extra/iemnet/udpsend.pd_linux Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] KMI SoftStep foot controller?
On 08/03/14 06:24, Jonghyun Kim wrote: Thanks Chris for the answer! I was worried about compatibility with Pd. How about OSC function with Pd? It's OSC works with [netsend] or [udpsend]? [your OSC message( | [packOSC] | [udpsend] pd-osc: /usr/lib/pd/extra/osc/packOSC.pd_linux pd-iemnet: /usr/lib/pd/extra/iemnet/udpsend.pd_linux Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
On 25/02/14 02:28, Dan Wilcox wrote: They have an SDK, so I imagine you can get the data out and send it over OSC. At least thats my plan when I get my dev Myo … :D then they aren't saying go away after all ... some data is available, presumably already analysed which would be quick and easy to use, at least for the pre-defined gestures. What is the pricing? From: Richie Cynglerglitch...@gmail.com Ha! Excellent point, I guess it's the pirate me interested in their tech but refusing to accept their terms. The original Kinect was packaged similarly and cracked within what weeks if not days? Although granted that was I think unique technology at the time. On Sun, Feb 23, 2014 at 4:05 PM, Simon Wisesimonzw...@gmail.com wrote: On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] threads in pd, dataflow
On 23/02/14 08:16, Jonathan Wilkes wrote: On 02/21/2014 10:04 PM, Simon Wise wrote: On 22/02/14 06:28, Jonathan Wilkes wrote: On 02/21/2014 06:41 AM, Simon Wise wrote: Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent. I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order. [...] Even the dsp-gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches. To know whether a control branch interacts with the signal domain is to solve the halting problem, no? especially not if you allow a little syntactical help from the programmer .. as you note here. And note the point of this is that generally the interaction with the dsp does not have to be in zero logical time after it is initiated, although often discrete sequences of interactions must be applied together in a single dsp timeslice. But also consider we are already making several simplifying assumptions and arbitrary (sometimes confusing) decisions as we turn the graph drawn as the pd patch into trees in the dsp and the message domains so that we can traverse them separately. If we allow fan-outs as parallel branches we change one of those arbitrary decisions. Instead of assigning an arbitrary order and re-writing the fan-out as a trigger we create new independent trees which we execute via a scheduler that runs in a similar way to any very basic OS scheduler ... when data is received for that tree it is put on a queue and executed the next time one of the cpu threads that pd has running is free. The usual priority queue stuff could be implemented regarding dsp interaction, scheduling on a basic level is very mundane stuff ... optimisations of all sorts at this point have been very well studied and can get as complex as you want. Note that we already break cycles in the graph, so we can indeed take each branch as a separate tree. There are obviously interesting complications and decisions regarding cold inlets, however the point of this is that by using a fan out the programmer is indicating that the branches may be run in parallel so cold inlets with data coming from outside should simply be updated whenever that data arrives ... use a trigger to ensure it is all part of the same tree if that is not good. But you could have some kind of seal object that verifies the user thinks a subpatch or canvas is 100% pure control domain. And then Pd could take that to mean throw it in its own thread (and throw warnings/errors if it finds a message going to a signal object, or fudging with dsp in any way). It could look like a wax seal and always be at the top-left of the patch. that's somewhat like the notion in functional languages of 'pure' functions compared to ones with side effects, in this context the dsp could be considered as a side effect, in the same way any output from a functional program is ultimately a side effect. Each functional language deals with this differently, and they are useful in different contexts. Unless you get into seriously strange constructs like monads for output and remain a strictly pure language (lambda calculus is turing-complete after all) there is some syntactical way (like your wax seal) to flag non-pure objects. In pd the ~ naming convention already does this, and could be enforced by the interpreter. In pd the dsp and message passing domains are dealt with quite separately, and if we wanted to treat the message passing domain as a parallelisable dataflow graph with its effect on the dsp as one of its outputs (a side effect in functional languages jargon) then there is a wealth of research and implementations in the functional area to look into as a comparison. A very crucial point here is that separating gui from dsp so that gui calculations do not block dsp means allowing
Re: [PD] threads in pd, dataflow
On 23/02/14 15:13, Simon Wise wrote: Note that we already break cycles in the graph, so we can indeed take each branch as a separate tree. ... but it is more an unroll than a break, or rather an exploration of the graph as a tree which may revisit the same nodes ... programmer beware of infinite loops, We can still create separate branches easily enough, if they overlap that is fine, the overlapping parts are simply included in each tree separately ... again programmer beware of the consequences and benefits of choosing a dataflow fanout rather than a trigger. It is in the dsp domain we make choices and break cycles in the graph by passing the data to the next block instead to allow loops to work as expected. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On 21/02/14 20:41, Charles Goyard wrote: Hi, just to give some example of single vs multi-threaded, and some comparison points. - projects like haproxy and lighthttpd show that good state machine programming can be more efficient that multi-threaded programming, even on multi-core computers. BUT they handle a much reduced number of use cases. - graphics chipsets are massively parallel. They handle huge amounts of data. BUT they are hard to build, they also handle a much recuced number of use cases, CUDA and OpenCL being a generalization. - (on windows) has its core single-threaded, and a lot of objects are multi-threaded, just like pd. It suffers the same than pd: when you get interactive with the GUI, the framerate slows down dramatically. - whitecat (a DMX software) has its GUI that runs on OpenGL, and it's not that efficient. In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much. [pd~] deals with the particular case of creating an extra dsp thread, it incurs overhead to do so and does not isolate the dsp from a busy patch. It is quite orthogonal to creating separate gui, video, audio or whatever threads. What I guess you mean is very different .. an object to launch a distinct pd process within (and isolated from) the rest of a pd patch. But I am not sure how that would be any better or more human-readable than 2 pd instances with [netsend]s and a suitable script to launch them together. Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] threads in pd, dataflow
On 22/02/14 06:28, Jonathan Wilkes wrote: On 02/21/2014 06:41 AM, Simon Wise wrote: Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent. I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order. Certainly in many audio patches the messaging load is small compared to the dsp, except when you add lots of gui elements to the patch. For them parallelising the messaging like this would indeed be pointless since a 2 thread solution with all the control interface in one instance of pd and all the dsp in another with both launched together from a script as the 'app' or using [shell] to launch the dsp instance makes a lot of sense ... here there is an obvious split for a separate thread. Since many modern computers are multicore and the dsp is only running on as many threads as you can devise with [pd~]s there is still plenty of idle cpu. I believe other languages have addressed parallelising the dsp graph in a more automated way but in pd this is done explicitly. For a single core raspberry or such the dsp thread can be given a higher priority so at least the audio isn't interrupted by too much interaction with the interface. However pd is used for much more than audio. Dataflow programming is inherently parallel but the implementation in pd comes from a single core history (well, a single messaging core controlling a separate dsp if you go back far enough) and is sequential. Hence the whole trigger - fanout discussion, in pd fanouts are not really dataflow fanouts at all, just ill-defined triggers. The implementation is a sequential depth first tree traversal and triggers make that explicit. Even the dsp-gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches. Also splitting the dsp graph where ~ objects are in a distinct dataflow branch would make sense (there would need to be some decisions regarding exactly what distinct means in this context). A good implementation would follow the lead of other languages and wouldn't just create zillions of system threads to throw at the OS, but rather have a way of grouping them into a smaller number of ongoing system level processes. Writing and optimising this would be a huge project, and a patch run in a dataflow implementation would not behave in exactly the same way as it would in a sequential one, it couldn't. But it is still an interesting thought experiment in the context of thinking about the future of pd in a world where a single thread sequential implementation is becoming increasingly problematic ... computers have been getting faster by adding cores rather than increasing clock speeds for some time now and that is not likely to change any time soon (quantum computing would be a whole new game and none of this would be relevant). Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 10/02/14 20:27, Lorenzo Sutton wrote: Hi Pall, On 10/02/2014 04:45, Pall Thayer wrote: This was a faculty grant at a US arts-focused college. I would say that 95% of students, 80% of faculty use Apple products. That really doesn't matter though. As you asked for feedback.. I think it does. I'm not proposing the usual (sterile) apple vs. xyz flame, but I've noticed this mac for music thing in academia and conservatoires over here (Italy). One thing that surprised me is the attachment to this ecosystem in the electoacoustic music landscape, where one would expect people to experiment as much as possible with unknown and unfamiliar tools in all directions. What is also interesting is to understand if the use of Apple products and software (e.g. MAX/MSP) is truly justified by creative/artistic needs or if it's just a matter of habit/convenience (this question in a neutral way, i.e. nothing against convenience). 15 years ago editing video was very much better on a mac than any other comparably priced system, this certainly helped encourage many AV people to learn the mac way. While they still used powerPC chips there were a lot of advantages to OSX over linux for working with video in pd. A few good audio apps have been available on mac for a lot longer than that, and macs have been pretty consistently easy to set up for common audio workflows ... providing you stick with mac friendly hardware purchases and adapt your practice those workflows. Much earlier Apple had got a lot of designers on board in a similar way with desktop publishing. Learning to use an OS is a lot of invested time, changing OSes means a new investment of time. Apple understands this and has often made it quite cheap for educational institutions to get macs to teach on and has kept transitions between versions reasonably easy for the user, so a lot of students and artists with a bit of cash to throw at good equipment learn OSX, then go on to use it rather than learn another and when it comes time to pick a platform to teach on or recommend to others ... Habit and already invested time, plus decent equipment and effective tools available without changing OS are a quite persuasive combination. Now on a hand-held level apple hardware is again significantly better than other stuff for some media and audio uses. But you miss out on quite a lot too, and educational institutions should try to broaden their students' experience rather than just go with what is easiest. Simon I'm not sure how (much) this fits in the topic you're going to address, but I think it's an interesting angle to take into account. And I'll be happy to share my personal experiences further if you think it's interesting (as I guess my email was already rather long) Ciao, Lorenzo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 11/02/14 04:40, Jonathan Wilkes wrote: Unfortunately the open source definition was designed to subtly hide the ethical reasons for doing open source development. The reasoning for this was quite straightforward-- share with your neighbor doesn't attract business dollars. So open source advocates focus on efficiency, like the ability to plug a 3-clause BSD-licensed library into just about any device you want, even a device that is locked down and requires the final app to be proprietary. If you consider attracting business dollars actually spent on ongoing development of open source code then the GPL, explicitly stating its aims and with strict copyleft terms has been quite successful (not denying that BSD, Apache and similar have also, in many cases) If anyone wants to read a principled statement on user freedom, it's here: http://www.gnu.org/philosophy/free-sw.html -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Infinite Permissions Loop
On 11/02/14 08:24, Wesley Boynton wrote: Hello, all! I am currently using PD-Extended in both OSX 10.8 and 10.9 environments. On our administrator accounts, we installed X11 and everything went fine. It launches and all is well. However, in our primary user accounts, we're greeted with a You don't have permission to use the application 'Pd-extended' dialog. Repeatedly. No matter how many times I grant it permission on an always or one-off basis, it continues to pop up the same dialog until I surrender and click OK. This is, by the way, all despite the fact that PD and X11 are on the list of Parental Control-Approved applications for use. Any input would be extremely appreciated and valuable. maybe you need Wish and/or Pd-extended and/or pd-gui or something on that safe list as well? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Infinite Permissions Loop
On 11/02/14 09:43, Wesley Boynton wrote: No such luck, unfortunately. All pd-related programs have the necessary permissions, yet I am still stuck in the loop. then maybe you need to turn off the offending filter all together. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Infinite Permissions Loop
On 11/02/14 09:43, Wesley Boynton wrote: No such luck, unfortunately. All pd-related programs have the necessary permissions, yet I am still stuck in the loop. try checking the path and permissions of the executables ... maybe your administrator path is different, or the limited accounts can't execute when they do find them? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 11/02/14 10:46, Jonathan Wilkes wrote: On 02/10/2014 05:31 PM, Simon Wise wrote: On 11/02/14 04:40, Jonathan Wilkes wrote: Unfortunately the open source definition was designed to subtly hide the ethical reasons for doing open source development. The reasoning for this was quite straightforward-- share with your neighbor doesn't attract business dollars. So open source advocates focus on efficiency, like the ability to plug a 3-clause BSD-licensed library into just about any device you want, even a device that is locked down and requires the final app to be proprietary. If you consider attracting business dollars actually spent on ongoing development of open source code then the GPL, explicitly stating its aims and with strict copyleft terms has been quite successful (not denying that BSD, Apache and similar have also, in many cases) That's true, but an open source advocate could still reframe that in terms of efficiency, cost-savings, etc., rather than freedom for the end user. An open source advocate could even make the argument that the GPL actually gets in the way even for the most successful projects that are licensed with it, creating unnecessary bureaucracy and copyright sign-off requirements in what would otherwise be a post-license digital utopia. looking from a commercial perspective (since it is helpful to understand how others may think, in this case the managers of business dollars) ... one fear that some businesses have about open source is that they don't want to pay for development that can then be used by other businesses chasing the same sales revenue. An advantage of copyleft to them is that it is a two-way arrangement ... another such business is obliged to give their own improvements back in return since selling a privatised, moderately improved version of a copyleft work is not allowed. I don't buy those arguments, but the point is that if there are enough voices framing everything in those terms then fundamental principles about user freedom get lost. I mean, if I'd never heard much about freedom of the press then who knows if I'd find it reasonable to prosecute journalists who receive classified information and sell it to their publishers in the form of news. Instead, that sounds like tyranny to me. And that's more likely due to a long line of teachers with the integrity to explain those principles than to living in a country licensed under the Constitution. :) indeed, I agree that the stronger GPL position is the better one in a world entangled with dubious copyright laws, or even one which simply embraces trade secrets and a market economy. It is becoming increasingly obvious that the biggest software systems are beyond the capacity of even giant corporations to maintain alone and collaboration is the only feasible way. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 09/02/14 16:34, Jonathan Wilkes wrote: On 02/08/2014 11:44 PM, Simon Wise wrote: ... It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. It sounds like you are rationalizing and encouraging non-development. More pointing out the frustrations that have been experienced in the past, and noting that decisions about what is added to Pd core are very consistent and are very careful, cautious and slow in these areas in particular. As you pointed out adding something like a string type without introducing it to [print] is not good, so ... you use clumsy workarounds that don't actually allow strings in messages, perhaps just pointers to stings with arcane results in [print] ... or write a bunch of replacement core objects that recognise strings to use within the library such as [stringprint] etc ... or use a fork with enhanced types and core objects that may or may not be compatible with some eventual core string type. It may be worth enhancing pd-l2ork this way as it has already departed considerably from pd, their choice has been to speed up development by bypassing these issues and pushing ahead without integration with core Pd, but I think adding strings confined to a small set of string-aware objects which remain otherwise compatible with vanilla the way gridflow added matrices isn't worth it, there is a much greater pay-off with matrices ... gridflow is a huge project with a very substantial library of matrix operations, while the authors long ago abandoned hope of their efforts being included in vanilla and develop in parallel. Development effort on a smaller scale is probably better spent in ways that will integrate with core pd, and there are plenty of those ... including your own solid efforts. But it also sounds like we agree that there is nothing about boxes of text connected with lines that makes string manipulation more difficult than lines of text. Absolutely, just the absence of a well defined string type that can be sent down those lines. Arguments advancing the addition of a string selector to Pd core are very worthwhile, I guess probably on pd-dev? it ultimately is a discussion with Miller. There was a link to something being worked on currently, earlier in this thread. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 10/02/14 11:53, Pall Thayer wrote: I'm giving a presentation this week. In a way, it's a counter argument to a recent presentation on Max/MSP. One of the things that I want to highlight is the open sourceness of PD. libpd presents a very good argument and I'll be highlighting a project I was involved with that produced an IOS app that used libpd as the audio engine. Is there anything else I should be considering besides the obvious points of open source being open source. Concrete examples of PD's open sourceness trumping proprietary technologies? IOs is an odd choice for talking about open source when the only way to install such an app in a device (without jailbreaking it or paying the developer tithe) is by licensing the binary closed source (on their terms) to Apple to distribute via their platform-monopoly app store, which will not distribute the sources or GPL or LGPL apps? Certainly licenses such as libpd's BSD like one do allow reuse of the code in any app, open source or otherwise, but then is that use still open source??? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 10/02/14 13:36, Pall Thayer wrote: This is where things enter into the odd world of academia. In all honesty, I think our application for the particular grant that was available was an outlier. The grant came with caveats. Projects were to target technology that would likely be used by faculty and students and the resulting work (publications or, in our case, software) would be released under open licenses. As far as I could tell, ours was the only project that was producing actual software. We were able to pay the Apple Dev fee for one year from our funds but our application wasn't ready for distribution within that time so we never submitted it to the app store and have released the source code instead. We were never big fans of distributing it through the app store anyway. Well I guess the target platform is jail-broken Apples then. Re academia ... I spent the last few years studying in an Australian university, maths and computing ... the students were a reasonable mix of linux, mac and windows users, not sure about the android/iOS split, while the staff and teaching had a somewhat stronger emphasis on linux and open source than the students. Matlab was the main exception to this. As a target platform android certainly has a much bigger user base worldwide than jail-broken iOS, though the apples may be much better for some audio uses. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 10/02/14 14:45, Pall Thayer wrote: This was a faculty grant at a US arts-focused college. I would say that 95% of students, 80% of faculty use Apple products. That really doesn't matter though. The project is out there. It can be ported to any platform if people want. More than anything, it was a proof-of-concept project. If it bothers you that this was developed as an IOS app then, by all means, take it and turn it into an Android app. No, it doesn't bother me (and if it is BSD licensed or similar then any enterprising person with a developer account could reasonably make it available for a dollar or so to the rest of the apple user base, and split the revenue with Apple, so it isn't really restricted to jail-broken devices). Apple is a good platform for lots of audio, I've used it a lot in the past. I was more interested in the Apple-centric academic world your choice implied, and the contrast to the situation here. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 10/02/14 14:46, Pall Thayer wrote: https://github.com/pallthayer/gesturalmusic It's GPL, so no enterprising re-distribution allowed. I'll give it a try if I get time with an iOS device. Thanks, Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is open source better?
On 10/02/14 11:53, Pall Thayer wrote: is the open sourceness of PD. libpd presents a very good argument and I'll be highlighting a project I was involved with that produced an IOS app that used libpd as the audio engine. Is there anything else I should be considering besides the obvious points of open source being open source. Concrete examples of PD's open sourceness trumping proprietary technologies? Well before libpd there was a port to Sony's gaming platform, and the audio engine was used for at least a game or two. Mark Danks of GEM fame ended up with a job at sony, the port was apparently available to sony partners. It was pd, but the port was not open source, so no-one outside got any access to it. http://lists.puredata.info/pipermail/pd-list/2007-11/056300.html Don't quite know where that fits as an example of the advantages of open source code, and since it became closed in the process there wasn't much trumping going on and hasn't been heard of since. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 09/02/14 07:59, Jonathan Wilkes wrote: On 02/08/2014 01:40 PM, Martin Peach wrote: A few years ago I implemented a patch for strings in Pd that adds a string or blob type that allows (I think) for what you are describing. I believe it's still part of Pd extended, but Miller didn't like it for some reason. ... I prefer to manipulate strings in a another language as it just seems like a lot of work to make it happen with boxes and wires when you can just call string functions in a high level language. ... Kind of like building a Turing machine holes-in-paper-tape version of a program, it can be an interesting exercise but practically it's useless. Read in transcript of congressional testimony on NSA surveillance. Split into one string for each line. Read one line every second. If a line contains the word terrorism make a sound. User takes a drink. Totally useful. :) What is it about boxes connected with lines that you think makes this difficult? Perhaps it is the long term and very well established resistance to adding a few types to the message syntax ... integers capable of indexing reasonable file lengths, strings which don't flood the symbol table, floats that aren't in danger of being truncated, bytes or chars which won't trigger parsing issues. Matrices are available via an external library (gridflow, within its own externals including non-native print and so forth) and GPU video access is possible via GEM with its private message syntax, but core Pd is very focussed on what it originally set out to do. There have been some moves on this, just very slow and careful ones. A graphical dataflow language is very nice for dealing with DSP and with control and interaction logic, and for doing so in a bunch of machines distributed over a network. Pd has lots of good ways to receive and send control messages and link with hardware and other programs. But dataflow and procedural algorithms are quite different and parsing strings is a very common thing to do when programming ... if you are familiar with the procedural way and have a good set of tools available to abstract the details then its easier to just go with what you know. It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
On 07/02/14 09:56, Thomas Mayer wrote: On 06.02.2014 10:09, i go bananas wrote: Has anything been done to try to marry these together yet? PuREST JSON includes a sonification for Bitcoin values going back to 2011, but I guess, that is not what you wanted to know. it sounds the more likely kind of dsp/bitcoin marriage, otherwise perhaps a pd concert with the ticket price in bitcoin??? simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
On 05/02/14 21:55, Ed Kelly wrote: Hi Dan, Miller et al. I'm still somewhat confused about the LGPL issues with regarding apps. Say I make an app that uses LibPd, and include an object or library that is licensed with an LGPL license. Would I have to include all source code for the app itself, or would it be sufficient to provide object files and source code for just the LGPL library I have used? The whole point of LGPL is to allow using a library with incompatibly licensed apps, while still keeping copyleft licensing for the library itself. see the licences for details ... http://www.gnu.org/licenses/lgpl.html http://www.gnu.org/licenses/lgpl-2.1.html you do not need to provide sources for the apps using the library (as you do when distributing an application linked with GPLed libraries). But you do need to ensure users are free to modify the LGPL library and use their own version with the app. Much of the discussion below was prompted by questions about using libraries with iOS and in particular compatibility with Apples stores. Apple hasn't allowed either GPL or LGPL software on their app stores, libPd avoided expr etc to conform with Apple's policies and hence be allowed on Apples app stores. Changing to LGPL won't change that, Apple does not like copyleft. Simon Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ On Sunday, 26 January 2014, 19:29, Dan Wilcoxdanomat...@gmail.com wrote: Howdy Miller, Sorry to bring this up again. The license in the expr source code headers has been updated to LGPL, but I just noticed the post in vexp_if.c line 386 still reads: expr, expr~, fexpr~ version %s under GNU General Public License . On Oct 5, 2013, at 8:53 PM, Dan Wilcoxdanomat...@gmail.com wrote: Awesome, thank you. I'm glad we could figure it out. I remember checking a few times and we discussed this in libpd. I kept getting confused by the different licenses. On Oct 6, 2013, at 3:55 AM, Miller Puckettem...@ucsd.edu wrote: OK... done and pushed to git repo. cheers M On Sat, Oct 05, 2013 at 12:18:23PM -0700, Miller Puckette wrote: Hmm... Looking back in the git repo i saw: commit 42f3e5f8dbc60ad644e9f8a1c5b61d1847e19470 Author: Miller Puckettem...@ucsd.edu Date: Thu Nov 3 11:40:35 2011 -0700 change expr~ source to LGPL license (with IRCAMs permission :) I had quite forgotten about this (and still can't remember this ever having happened) but here's the e-mail I got from Shahrokh: On Tue, Oct 25, 2011 at 02:50:53AM -0700, Shahrokh Yadegari wrote: Dear Max and Miller, I got news from IRCAM that they are willing to release expr code on LGPL. Will that solve the current licensing problems? Max, could you communicate to the list and let me know what they think about this. I hope this helps. thanks, Shahrokh So I think we're in the clear (although I hope Shahrokh kept the mail from IRCAM authorizing this!) I'll go on and change the source over here so that it appears in the git repo. (This will take some time as I first want to merge my 0.45 fixes into 'master'.) cheers Miller Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
On 06/02/14 00:36, Dan Wilcox wrote: Short answer: yes, it's sufficient to provide the object files and static libs As far as my understanding of GPL LGPL goes, you do not need to publish your app sources when using LGPL libraries as the Lesser part of the LGPL allows for distribution and is not viral. yes, though 'viral' is a misleading term ... the GPL does not, cannot, change any license for any other code, it is not infectious. The GPL is certainly more restrictive (regarding re-distribution, not use, of the code covered) than for example the BSD or LGPL. It restricts the right to distribute/propagate as part of a larger work to works where the whole of the source code of that work is made available for reuse, modification and re-distribution either under the GPL or in any less restrictive way. In the second case the GPLed code would no longer be licensed for distribution (and would have to be replaced or dropped or a different license negotiated with its copyright owners) if the work as a whole was modified and distributed with a more restrictive license. Whether this is useful or not has been very widely debated. The motivation for the GPL is stated in the license and the LGPL was written to cover some cases where the authors considered a less restrictive license useful. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mouse icons
On 25/01/14 09:59, Peter P. wrote: Simon Wise wrote: They are certainly are system icons, they change if I change the system cursor theme. In xfce different sets of icons are selectable as themes for the mouse. But here there has always been one missing ... the one shown while hovering over an inlet or outlet in edit mode, but it never bothered me enough to find out why, and anyway I've got an oldish pd installed so it may have been fixed already. thank you! I was able to select a theme that suited me better using (under Debian) sudo update-alternatives --config x-cursor-theme Now I am looking for a way to disable the arrow-cursor that is mirrored directions when you hover the mouse over an object that can be clicked and use the normal error for it. But somehow I can't find the file that holds the cursors themselves. Otherwise I could delete the mirrored arrow file and use a symlink pointing to the original arrow. the themes seem to be in /usr/share/icons/ with the cursors in X11 cursor format, and a couple of configuration files, maybe you could copy a folder and customise a theme to your liking. I feel that there could be less different mouse cursors in Pd in general, somehow it is already quite a lot: Personally I like the feedback that the changing cursors give, sometimes the target areas are quit close together or small, eg it is nice to know when you are over an outlet that is suitable for the connection you are trying to make, and simple visual feedback is quite important in any modal application .. I prefer an edit-mode cursor to some indication in another part of the window. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Multi-input USB audio into Raspberry Pi
On 24/01/14 01:52, Chris McCormick wrote: Hi all, I might be really pushing my luck here, what with all the reports of audio issues on the Pi, but has anyone heard of somebody getting multi-input audio working with a multi-input USB 2.0 audio device? I have a dream of running one of these mixers (which does 8 channel audio out over USB 2.0) into Pd and being able to manipulate all of the channels from the mixer in Pd: http://www.alesis.com/multimix8usb20 given they need audio drivers for windows and mac I don't like your chances on linux, let alone a Pi, except perhaps the USB1.1 mode with 2-in 2-out. Apparently the esi gigaport hd+ does 8 channels OUT from the Pis, but I have not heard of any devices working with 8 IN. By the way ... finished my degree and I'm now in Sydney, if you're heading this side of he country sometime let me know. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mouse icons
On 24/01/14 07:48, Peter P. wrote: Hi, I am on Pd-0.45.0 vanilla compiled from Miller's git sources on Linux with Tcl/Tk 8.5.0-2.1 In what sense are the mouse icons that Pd uses dependent on the operating system? I feel they have changed in a way that confuses me since I compiled Pd on a new Debian box. So it might either be Debian, or Pd. Does anyone have an idea how they could be interrelated? Thanks for you comments! They are certainly are system icons, they change if I change the system cursor theme. In xfce different sets of icons are selectable as themes for the mouse. But here there has always been one missing ... the one shown while hovering over an inlet or outlet in edit mode, but it never bothered me enough to find out why, and anyway I've got an oldish pd installed so it may have been fixed already. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
On 31/12/13 08:30, Dan Wilcox wrote: Ouch. I guess alot of us don't have serious projects :D (Out of curiosity, does Max do soft clipping also?) the point was that OSX was messing with the sound between the software, presumably any software, and the audio output ... which may perhaps be called a feature while listening to songs in iTunes but is a big worry if you are trying to use the system seriously as a musician. It is a problem that comes up on this list from time to time, I don't recall any reply saying it could be bypassed or turned off. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
On 01/01/14 11:32, Chris Clepper wrote: It's very, very easy to avoid any sort of clipping processing by using hardware with drivers that don't have any! Avid, Apogee, MOTU, RME, and many others have bit transparent OSX CoreAudio drivers. Also, any DAC worth it's using can reconstruct far beyond 0dBFS without distortion, so hearing volume increase past -1..1 in software is not surprising. I recall the ADI 1955 and equivalent TI part putting out +12dBFS or something ridiculous, but those ain't Wolfson low power headphone codecs neither! So it is the driver for the built-in audio output that is adding the feature/problem? I rarely use OSX these days, just an old setup with a G4 mac mini and a MOTU that hasn't been updated for years but still does its job nicely. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creating random filenames
On 30/12/13 00:10, Jack wrote: Le 29/12/2013 13:17, Ronni Montoya a écrit : Hi, how can i create random file names in pd? I need to have a recording button in my patch that everytimes records an audio file in a different ( random ) file name. For example, each time i record something it should create random .wav file names: kasdsd.wav lifasik.wav kjaskld.wav etc any idea how to achieve this? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list A solution without external... just use something like [symbol $1$2$3$4.wav( to replace [list2symbol] if you really can't use it Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using rpi_osc_video_player
On 06/11/13 16:10, Antoine Villeret wrote: hi, nice to hear that you try and like it ! concerning the video encoding, you could do that with ffmpeg or avconv but i never try it, so I don't know which parameters work I haven't managed on ffmpeg yet, but the person making the content is working on OSX and exporting to the blu-ray format gives the right file format. and concerning new features, feel free to add some ! I'm waiting for a project (or at least funding) to add seeking, playback speed control and to improve remote control playback speed is working, seeking I must get working this week! and with luck the ability to add overlays, to mask areas and add image files with text. I'll make a generic pd patch to control 6 Pis, but won't have time for anything except something quite raw to start with. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] using rpi_osc_video_player
I've finally got back to working with video on the RPi, and Antoine's player is very useful. I am hoping to add alpha, layers and still images to it, and the ability to seek to the start of the video (at least). The current code is working, playing back the sample test.h264 file nicely but seems only to recognise the .h264 container ... do you know how to convert .mov files (that play well in omxplayer) to that file format? Also I am getting an error when I stop a thread ... OMX_FillThisBuffer(ilclient_get_handle(video_render), eglBuffer) at line 68 of video.c is failing. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] using rpi_osc_video_player
I've finally got back to working with video on the RPi, and Antoine's player is very useful. I am hoping to add alpha, layers and still images to it, and the ability to seek to the start of the video (at least). The current code is working, playing back the sample test.h264 file nicely but seems only to recognise the .h264 container ... do you know how to convert .mov files (that play well in omxplayer) to that file format? Also I am getting an error when I stop a thread ... OMX_FillThisBuffer(ilclient_get_handle(video_render), eglBuffer) at line 68 of video.c is failing. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 23/10/13 05:12, Jonathan Wilkes wrote: Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) I don't think their main ppc target is Apples now, and the Open Firmware boot system is very old, I think you need to go back a few versions to get a debian installer that still does that, then maybe you can upgrade from there, but I imagine newer ppc stuff won't be using altivec, and without altivec and the quicktime stuff optimised for it they are not so useful, really it is probably much more sensible to run OSX 10.4.9 on them and a pd that runs on that. I have an old ppc mac-mini still running from the days I used OSX, it is running an old debian. I never bought any intel macs, but certainly it took years before the intel mac-minis caught up to the speed of the G4 ones in terms of editing and playing video. Back in early Final Cut Pro days the ppc apples could run video editing much better than anything else even close to the price, but that is ancient history now and Apple mostly sells hand-held gadgets now. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] reading tables indices with liner interpoation
On 05/10/13 15:52, peiman khosravi wrote: Hello, Thanks for the reply. The thing is that I need to get discrete values to write to another table. So if I input 0.5 I want to get the exact mean of the first and second array elements. I guess it could be done manually in an abstract, but it'd probably be much slower. why not use the [linear_path] object you mentioned, if you want to avoid doing the calculations directly??? there is no reason for another external to do the same job as an already existing one. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
On 05/10/13 01:47, Dan Wilcox wrote: Actually no. This is a common misconception. The GPL does *not* forbid selling GPL software! The requirement is that you have to publish *all source* and especially modifications you make. It also very explicitly allows using it yourself in any way, modified, combined, whatever, without restriction ... it only requires publishing the sources if you distribute it. On Oct 5, 2013, at 12:33 AM, pd-list-requ...@iem.at wrote: From: Pagano, Patrickp...@digitalworlds.ufl.edu Subject: Re: [PD] Legal restrictions for apps Date: October 4, 2013 1:37:21 AM GMT+08:00 To: Simon Wisesimonzw...@gmail.com Cc: pd-listPd-list@iem.at There was quite a lot of discussion on the supercollider list about this too. Everyone is quick to share that you can't sell it. I don't want to sell anything I want to use the programs for my own use on a tablet, plain and simple. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
On 03/10/13 10:39, Jonathan Wilkes wrote: And make sure that all the authors sign off on that license change. this was the subject of a long discussion on this list and discussions with the authors and copyright holders, check the archives for details, the license change was not done arbitrarily, the copyright holders decided to replace GPL by LGPL and took some time and care about it so I assume they did so properly. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
On 03/10/13 03:17, Tony Hillerson wrote: I agree that it seems like there's there's no prohibition on distributing LPGL objects You must distribute them under the LGPL, and that requires making their source code available, just like the GPL. However LGPL programs/libraries can be linked to from any program, unlike GPL code which does not allow distribution unless all the sources including that of any code which links to it are also distributed with compatible rights but not necessarily obligations. Distributing an LGPL binary you must still distribute its source as well (in one of the ways described in the license). Then you may distribute it under the LGPL license. Apple does not allow GPL software on its appstore. To distribute a program on the appstore you must give Apple a license to distribute it, in return they collect license fees and pay you part of what they collect, but they are not willing to agree to the GPL and are not willing to agree to make the sources available under those conditions. You are not in a position to give Apple any license to distribute expr except the LGPL, and certainly cannot give them the right to distribute it without them agreeing to the obligations regarding expr source code, which would seem to put it in the same situation as GPL programs. But is expr part of libpd?? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] from poles/zeros to biquad coefficients - how to? (something like max's z-plane)
On 24/09/13 21:46, Funs Seelen wrote: On Tue, Sep 24, 2013 at 3:35 PM, Alexandre Torres Porres por...@gmail.comwrote: so you're basically saying all i need to use is use only the real part, right? No, I meant that I have the idea that the imaginary part in the calculated coefficients will disappear automatically if you add complex conjugates for all poles and zeros, probably when somehow i^2 gets -1 somewhere. But I must say I'm not a mathematician and not sure at all. indeed it will ... a conjugate is the number with the imaginary part negated ... so adding a number and its conjugate will certainly end up with a real part only. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cannot get [hid] to work properly with my mouse
On 23/09/13 20:10, s p wrote: The patch I am doing is for a workshop, so I'd like to be platform independent... But thanks for the tip anyways! platform independent plus using input is going to be quite limited, since under the surface there will be quite different implementations per platform in any cross platform object or environment ... which may or may not be consistent. Of course with simpler and more abstracted data you may have more luck. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Migrate away from Sourceforge?
On 31/08/13 06:46, Thomas Mayer wrote: I cannot vouch, that any commercial service will not do the same of course. Github e.g. stopped supporting downloads of binaries a few months ago. ISPs charge for bandwidth, in some places much more heavily than others, so for hosting lots of binaries without this kind of revenue raising you need to go through some big institution with serious bandwidth ... say a university, or the mirrors provided within various ISPs or academic networks, and accept their conditions to do so. Otherwise you can choose to only supply binaries to those people willing (and able) to join peer to peer file sharing networks, or willing and able to get their binaries through the big mirror system organised by Debian or similar. Essentially either abandon potential or existing users who only use commercial channels (maybe a few will actually learn, expand their horizons, and follow the move) or join their club, make use of their channels, and live with their techniques. It's a difficult choice, it depends on your goals. Github is offering binary downloads again, but I'd guess that can only continue if the volume stays reasonably small (i.e. if most users are there for the code, as developers ... and they distribute their binaries using other channels) or the revenue they can extract from the user in the process gets higher, or they can pass the bandwidth cost on to the projects as a paid service. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems with presets and midi controller
On 30/08/13 07:48, Ronni Montoya wrote: Im using the Killamix mini controller . This one: http://www.kentonuk.com/products/items/midicontrol/kmix-mini.shtml It has rotatory knobs, they are the type which can rotate endlessly, it has leds around the knobs . Is it possible to send the data from my preset (pd patch) to my controller and update the lights (value in each knob) ? Is it possible to update the values in my midi controller from my pd patch? a quick look at your manual suggests that you need to set the unit to listen to incoming midi, after you set that mode correctly then you will be able to send CC messages from pd to set the levels. The english is a bit twisted in the manual, but it seems that it sets the level for that CC for all channels not just the current one, which seems a bit limiting but still quite usable. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] send message to current pd-window
On 29/08/13 14:57, Ingo wrote: I was kind of hoping to find a simple and existing solution for globally sending hid inputs to the current Pd-patch / subpatch / window inside of Pd. Since I need this only for speeding up programming I found an external solution btnx to reprogram the mouse buttons for sending key commands. That does the trick for me. xbindkeys is a quite useful general tool for this kind of thing, mapping key or mouse combinations to commands, also if you want there is a scheme option for more intricate mappings of sequences etc. nice for configuring keystroke and mouse button independently of all the annoying desktop gui stuff. or triggerhappy (thd) which is similar but outside X Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems with presets and midi controller
On 29/08/13 11:28, Ronni Montoya wrote: when I'm playing with my midi controller and i change my preset in my patch and then i continue playing with my midi controller, the pd patch is gonna make a jump in the values of my slider, because my midi controllers has a memory and remember the last value it was playing. exactly how the midi controller works here depends on the controller, and how it is set up I was wondering which is the best way to avoid this problem. is it possible to upload my data (preset) to my midi controller? assuming the controller you are talking about is rotary knobs or sliders, then some of them have sliders with motors which will move the slider to match a value sent to that channel, but without motors obviously the position of the slider IS the memory of the last setting and you can't change that without using your fingers! BUT with some controllers you can set them to not send data until you have moved the slider to match the last value you sent to that channel. Clumsy, but much better than jumping back to the old value as soon as you move the slider. If you are a little careful the pd gui sliders and hardware motor sliders can be set to reflect each other and avoid fighting each other in a feedback loop. With rotary encoders, if they are the type which can rotate endlessly then usually they just work easily, and if your controller has leds around the knob to indicate the channel's current value then these are updated when you send to that channel. Rotary encoders with a fixed start and end point are like the sliders without motors, see above, they are fine when they are the only thing controlling a single channel, or when any new preset sent or channel switching is always to the fully up or down setting. If you are talking about buttons, often the controller has options regarding what the send, if they act as toggles or send set values etc. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Upcoming pd-l2ork release teaser
On 28/08/13 04:34, Jonathan Wilkes wrote: On 08/27/2013 12:56 PM, IOhannes m zmölnig wrote: On 08/27/13 18:20, Ivica Ico Bukvic wrote: to share a small but hopefully sweet teaser screenshot with everyone :-) while it does look pretty, i hope you are not going to start teaching people to use fan-out rather than [trigger]. Therefore, in cases where crossed wires or other ambiguities are not an issue, Fanout(1) is preferable to Trigger(2). Conclusion: teach Fanout(1) and Trigger(2) for situations where ordering doesn't matter, and Trigger(1) for situations where it does. The end. also, in a potential future with some kinds of parallelism in pd, taking Fanout (rather than Trigger) as an explicit statement that the branches are not dependent on order of execution is quite interesting, and very consistent with the ideal that Fanout order is undefined. But that is a dream-space a long way off for pd as it is now. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Upcoming pd-l2ork release teaser
On 28/08/13 11:36, Simon Wise wrote: also, in a potential future with some kinds of parallelism in pd, taking Fanout (rather than Trigger) as an explicit statement that the branches are not dependent on order of execution is quite interesting, and very consistent with the ideal that Fanout order is undefined. But that is a dream-space a long way off for pd as it is now. Of course interpreting Fanout as allowing asynchronous execution of the branches is somewhat stronger than taking Fanout to mean what it currently does, which is that the branches can be completed in any arbitrary sequence. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
On 26/08/13 22:03, me.grimm wrote: just currious, is all the work jonathon wilkes been doing on the pd gui stuff (search, preferences, etc) on OSX expected to be a part of Pd Vanilla? that is up to Miller, if it fits his plans or not, otherwise it's in extended, or imported manually where that is possible ... which is the same for all developments. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pointillism @ ICMC2013
On 12/08/13 15:35, IOhannes m zmölnig wrote: the ICMC2013 has started this morning in Perth/Australia. since i'm performing my piece pointillism tomorrow night at The Bakery/artrage (233 James Street Northbridge), it'd be great to meet with people who happen to be in the area. It would be great to meet up .. I'll try to get to the performance, maybe meet up for a beer or coffee? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pointillism @ ICMC2013
On 12/08/13 22:29, Chris McCormick wrote: On 12/08/13 15:51, Simon Wise wrote: On 12/08/13 15:35, IOhannes m zmölnig wrote: the ICMC2013 has started this morning in Perth/Australia. since i'm performing my piece pointillism tomorrow night at The Bakery/artrage (233 James Street Northbridge), it'd be great to meet with people who happen to be in the area. It would be great to meet up .. I'll try to get to the performance, maybe meet up for a beer or coffee? I'll be in on that! See you guys there. Perth being the kind of town it is, I can't stay late since I'm limited by the last bus home (and 4 years on a student income!) but I'll be there about 9pm. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get dir of current pd
On 30/07/13 22:04, yvan volochine wrote: I'd definitely go for the shell script solution.. although after some quick tests I didn't manage to run 2 different pd instances from one shell script... pd is your friend here, to run the process in the background Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: right angle connections
On 14/06/13 16:15, michael noble wrote: On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvici...@vt.edu wrote: While I agree with you that in most cases segmented patch cords are unnecessary, if you never have a need for them I presume you must be then using sends and receives for any situation where there is a feedback loop like: [object] x [object] Good point, I had a sneaking suspicion I was missing something. White space helps here, but this is is the one case where I reluctantly tolerate some obscuring the text. leaving the lines crossed this way also makes the construct instantly recognisable. I find that with the addition of an occasional [t a] object and a few send-return pairs when they give a clearer logical layout (plus putting appropriate logically related sections of the code in subpatches) makes a patch very readable, while tracing out segmented cords in big patches in other languages gets tiresome. Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT: raspberry pi
On 16/05/13 23:39, Max wrote: hi patrick Why don't you just use millers images with vanilla or the satellite-ccrma with pd-ext, both linked here: https://puredata.info/docs/raspberry-pi Both images are very close to 8GB (though much of that is empty space) ... the CCRMA one did fit my SD cards but the pd-la one was slightly too big. The raspbian wheezy image will fit on a much smaller card, and will expand its partition to fill what you have, and is working nicely here. Clearly not all 8GB cards are quite the full 8GB. http://downloads.raspberrypi.org/images/ If you try the standard debian armel it will probably work, but is compiled for a simpler CPU without hardware float (ARMv4 rather than v6), and will be slower. m. Am 16.05.2013 um 15:39 schrieb Patrick Paganobigsw...@ufl.edu: Hello i just received my first raspberry doo-hickey and i am wondering what distro people are using. I tried the wheezy last night and it seems okay, i installed pd-extended after a few tries I was unsuccessful with getting the CCRMA distro to load onto an 8GB chip i basically would like to have pd with pdp working, supercollider and i assume omxplayer ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] direct connection from pd to webrowser, low latency
On 29/04/13 01:36, o...@onyx-ashanti.com wrote: I implemented a version of an idea that had been done several times in the past ... a silent disco, where there are two djs playing to wireless headsets over 2 different channels ... with all sharing the same physical space. The result is quite fun, in our case it was in a public square and was all powered by people jumping onto bikes hooked up to alternators etc (well - I did have quite a large battery in the circuit just to be sure it wouldn't all wind down and get boring, but we did generate enough power almost all the time) was this using wifi? how were you able to implement it? was it a server type system or a broadcast system? might need to bike alternators as well to power this joint, lol. the audio side was just standard wireless hifi headphones, using lots of headphones but only two of the transmitters. The interesting part technically was the bike powered generators, but the 2 channel headphones dance floor and double DJ thing was lots of fun. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] direct connection from pd to webrowser, low latency
On 27/04/13 05:38, o...@onyx-ashanti.com wrote: On Apr 26, 2013 10:08 PM, katjakatjavet...@gmail.com wrote: Hi Onyx, What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system? Actually it a sonic space I want to explore. To play to people on their own personal bionic ear. Click and listen. The scope for experimentation intrigues me. Gestural binaural processing will be fun. I implemented a version of an idea that had been done several times in the past ... a silent disco, where there are two djs playing to wireless headsets over 2 different channels ... with all sharing the same physical space. The result is quite fun, in our case it was in a public square and was all powered by people jumping onto bikes hooked up to alternators etc (well - I did have quite a large battery in the circuit just to be sure it wouldn't all wind down and get boring, but we did generate enough power almost all the time) Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [LAU] 'Modular' midi controller for keyboard
On 30/03/13 05:35, rosea.grammostola wrote: The bcr2000 has rotary encoders with LEDS. The bitstream 3X does have potentiometers and it's possible to set the 3X in such a way that the know has to pass the value of an control in a certain software, before it gets 'on'. I find the need to move the knob (or a fader) to pick-up the value as above very clumsy in many circumstances ... especially when fine tuning something it is difficult to make the first small adjustment, and requires finding the target value first from the computer screen etc. Its OK if you have enough knobs so that you can control most things you want to without switching. Potentiometers seems to have the advantage of being more accurate and have a more analogue feel. I'm not so sure about the more accurate .. it is possible to scale the encoders so they need many rotations for the full sweep of values if you want very fine tuning, and the BFC2000 has 14 bit modes using 2 midi channels to make full use of this accuracy. You can do something like set the push-down position of the encoder to switch to the fine scaling if you want. And certainly compared to old rotary faders from analogue radio days the encoders are lacking some feel, but not compared to most of the smaller knobs on analogue mixers and such. The question is whether the X3 is good for controlling softsynths like AMS / Ingen and stuff like SuperCollider. Or are rotary encoders better for this. Certainly you can see smaller differences looking at the position of a (big) knob compared to the discrete values you can see from the ring of leds, but on the other hand leds can be very easily visible at a glance and the BCF2000 has several display modes to help keep track of its current purpose, again very handy if you are say switching between frequency, Q and gain or something like that. And of course looking at a knob that isn't an encoder you need to remember if you have picked-up its real value yet, or if it is still in the position left from its last purpose. IMO if you have enough knobs so you don't need to switch them between controls very often then they would be fine, but if you want to control more values than you have physical controllers the encoders, motor drive faders and the paging facilities on the BCF, BCR and similar is better. I've found the layout, leds and positioning of buttons n the BCF very useful for a very wide range of live control tasks, and its still going strong and many years old. The main thing that I have found missing on the BCF2000 is touch sensing on the faders, so that when a fader is touched that info is sent to the software. That feature is very useful in recording automations. Simon \r ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI abstraction issues
On 18/02/13 21:19, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-18 13:36, Esteban Viveros wrote: 2013/2/18 IOhannes m zmoelnigzmoel...@iem.at yes it is. You know someway to solve that issue?? currently the only way (i know of) is to make your [cnv] smal enough so that it doesn't hide the iolets. (or trust the user that they can connect without actually _seeing_ the iolets) or make little [cnv]s to indicate the iolets, then you can colour code them as well, if you are making that sort of interface Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RPi Video player was : Re: RPi - GEM openGL
On 17/02/13 17:51, Antoine Villeret wrote: hey Simon, I haven't check the JSON/RPC API of XBMC but yes I think there is some possibilty here Another way is to start with video player example like Ju said on his blog : http://w.xuv.be/projects/raspi_video_loop I'll give it a try next week and keep you aware. My goal is to be able to sync several RPi in a frame accurate way. yes - me too, that's the first step .. xbmc seems promising, the way I've done it very successfully in the past is just sending frame numbers to pix-video in gem, using the computer that was running audio as the master clock. My friend found that just using omxplayer kept quite good sync over 20 minutes or so, and she is quite picky about that kind of thing. I didn't see the result myself, it was on the other side of the world. After sync I want to tackle crossfades, which pdp might be able to achieve, then the kind of framing that can be done by moving a rectangle around in 3D, which will require some extra work. But not in a huge hurry, and a lot of other things to do, but should get my hands on a Pi in the next few weeks. I've got lots of existing GEM stuff I was running a few years ago using a mac mini per projector that I'd like to port to Pis. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Fwd: Re: RPi Video player was : Re: RPi - GEM openGL
sorry, first went privately by mistake ... On 17/02/13 22:47, dreamer wrote: I've got lots of existing GEM stuff I was running a few years ago using a mac mini per projector that I'd like to port to Pis. You'd need to start with porting entire GEM to OpenGLES. that would be nice, but very big. But actually the way my patches work I only need a few things from GEM ... create a window, read a video file, to texture it onto a rectangle and move it around. Most of the hard work in the patches was the control logic and the interfaces. It would be easier to port the patches to a new set of very basic video objects than to port GEM, and making those 4 or 5 objects in openGL-ES seems manageable. But doing it with GEM in mind may be a very small contribution towards porting GEM. http://archive.raspbian.org/raspbian/pool/main/p/pdp/ Looking in the raspbian repository and pdp is built there .. is it not working??? That could at least provide an xv window, video file playing and crossfading (hardware playback would only happen then if libquicktime was using it, but it's there raspbian ready to test later this week when I get some hardware in my hands. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdp on RPI (was RPi - GEM openGL)
On 17/02/13 23:33, me.grimm wrote: That's what I was assuming. How to build just pdp.pd_linux minus the pdp_opengl.pd_linux is the question I'll try later this afternoon if I get the chance does the raspbian package fail on raspbian?? I guess it must build, it has been built in the main debian repos for both armhf and armel for quite a long time. It does have the pdp-opengl binary, and it does depend on gsl etc so they must be there even if not working. http://archive.raspbian.org/raspbian/pool/main/p/pdp/ Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RPi - GEM openGL
On 16/02/13 20:16, Antoine Villeret wrote: hello, if by from within PD you mean triggering omxplayer from pd you can do that either by using [shell] like Simon explained or by using pdsend and pdreceive, this could be done remotely, here is an how to : http://antoine.villeret.free.fr/?p=600 cheers yes .. a pipe works fine as well. Antoine did you check out xbmc further, I don't have a Pi here at the moment but have been looking at the xbmc docs and it can be controlled directly through a TCP port, so you should be able to do a lot more control (via netsend etc). Perhaps only the media centre playlist, looping and seeking stuff ... no crossfades that I can see. There does seem to be some provision for custom effects somewhere, via shaders but it seems, but probably only in GL, not in GL-ES. Still ... accurate seeking could be useful, there seems to be access to a global clock and seeks in files ... both with high enough resolution to sync things well. I'll test that when I can when I get a chance. Has anyone tried using pdp on a Pi? again, I'll have a play when I've got one here. Pdp has an xv window, and a movie player that uses the linux quicktime library ... is the quicktime library available for Pi? and if so does it use the built-in codecs? ... that could be a way to go for fairly straightforward video playback. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdp on RPI (was RPi - GEM openGL)
On 17/02/13 01:25, me.grimm wrote: Has anyone tried using pdp on a Pi? i get: ../../include/pdp_matrix.h:25:27: fatal error: gsl/gsl_block.h: No such file or directory even when doing: ./configure --disable-glx --disable-gsl which gives me: --enable-mmx=no --enable-quicktime=yes --enable-v4l=yes --enable-pwc=auto --enable-sdl=yes --enable-x=yes --enable-xv=yes --enable-glx=no --enable-gsl=no --enable-png=yes --enable-debug=no ??? that looks like pdp_matrix is using shaders and therefore won't work on the Pi ... probably need to avoid building it, plus any other parts that are using shaders more clues on this below, bit it seems from a glance at google that OpenGL was an addition to pdp, but a while ago ... so there may be quite a lot that does not depend on it. I have two binaries in the /usr/lib/pd/extra/ ... pdp.pd_linux and pdp-opengl.pd_linux ... while in /usr/lib/pd-extended/extra/ I have just pdp/pdp.pd_linux, so they were obviously built quite differently. The one in extended came with a pd-extended deb, and presumably from the pd-extended build system, while the pdp-opengl.pd_linux came with the pd-pdp deb so maybe its worth building from the debian source package, but avoid building the opengl part Neither of these packages are very recent, but both work. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RPi - GEM openGL
On 13/02/13 21:15, João de Brito Rocha Reis Vidigal wrote: Ok... Hands on! I kinda need this... So guide me and I'll try my best! 1st - can I use pdp_xv on the RPi?... will it work? putting it very simply, the thing I need is really just a video window to throw some videos in... short videos and from time to time. meaning it is not a VJ machine... which it could be... but it ain't! if you really just need to play videos triggered by your pd patch then you can use the player that comes with the Pi, it can be played using [shell]. here is a very quick example I set up for a friend who wanted to play a bunch of videos on que, starting different videos together on 4 or 5 Pis cued from a laptop over wifi. It wasn't hard for her to get a screenfull of buttons to do the cues she wanted, and the Pis were great since she didn't have much time to set up in the venue, so her wifi network could be run and tested offsite. Plus the Pis worked out cheaper than buying long VGA cables etc. Anyway this worked for her .. obviously it is extremely limited, but it does let you play videos cued by pd. Just open pihelp.pd Now I want to get things a bit better, and see if I can put together a very simple set of pd objects to set up a window then play and crossfade a series of videos. Nothing fancy yet, but just getting that up will be a start. Unfortunately it can't happen too soon, I've got some other stuff on my plate too. Simon #N canvas 7 74 428 368 10; #X obj 36 118 starter; #X obj 250 117 playit; #X text 116 201 open me using right-click for more info; #X text 125 327 Simon Wise 2012; #X text 139 219 (or control-click on OSX); #X text 222 96 put this on each Pi ..; #X text 6 279 IMPORTANT: if [netsend] can't connect it will hang; #X text 5 294 for a long time \, until eventually it times out; #X text 77 27 sudo apt-get install pd-ggee; #X text 12 65 THEN:; #X text 11 4 FIRST: to get [shell] install package pd-ggee on the Pi's ; #X text 30 95 put this on your laptop; #N canvas 5 102 227 118 10; #X obj 31 23 netreceive 3001; #X floatatom 118 56 5 0 0 0 - - -; #X obj 31 52 ggee/shell; #X connect 0 0 2 0; #X connect 0 1 1 0; #N canvas 391 98 379 614 10; #X obj 185 300 netsend; #X msg 196 249 connect 192.168.0.11 3001; #X obj 101 88 bng 15 250 50 0 empty empty 1 5 8 0 10 -1794 -1 -262144 ; #X obj 97 23 bng 60 250 50 0 empty empty go 5 25 0 40 -1794 -1 -262144 ; #X obj 101 104 bng 15 250 50 0 empty empty 1 5 8 0 10 -173826 -1 -262144 ; #X obj 72 402 netsend; #X obj 121 88 bng 15 250 50 0 empty empty 2 5 8 0 10 -1794 -1 -262144 ; #X obj 121 104 bng 15 250 50 0 empty empty 2 5 8 0 10 -173826 -1 -262144 ; #X obj 177 489 netsend; #X obj 141 88 bng 15 250 50 0 empty empty 3 5 8 0 10 -1794 -1 -262144 ; #X obj 141 104 bng 15 250 50 0 empty empty 3 5 8 0 10 -173826 -1 -262144 ; #X msg 83 378 connect 192.168.0.12 3001; #X msg 188 466 connect 192.168.0.13 3001; #X msg 11 194 connect localhost 3001; #X text 11 175 for a local test ...; #X msg 11 220 send gvim; #X text 214 196 the command goes here ..; #X text 244 233 the address here; #X text 215 267 3001 is the port number; #X text 175 43 all go at once; #X text 173 89 green = go; #X text 172 104 brown = connect; #X text 135 589 Simon Wise 2012; #X text 185 58 (must be connected first); #X text 59 562 just edit commands and addreses to suit!; #X msg 185 211 send omxplayer fireleft.mov; #X msg 72 350 send omxplayer waterleft.mov; #X msg 177 437 send omxplayer fireright.mov; #X connect 1 0 0 0; #X connect 2 0 25 0; #X connect 3 0 2 0; #X connect 3 0 6 0; #X connect 3 0 9 0; #X connect 4 0 1 0; #X connect 6 0 26 0; #X connect 7 0 11 0; #X connect 9 0 27 0; #X connect 10 0 12 0; #X connect 11 0 5 0; #X connect 12 0 8 0; #X connect 13 0 0 0; #X connect 15 0 0 0; #X connect 25 0 0 0; #X connect 26 0 5 0; #X connect 27 0 8 0; #X coords 0 -1 1 1 75 120 1 90 2; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Range Slider Object
On 04/02/13 23:37, Simon Wise wrote: On 04/02/13 14:09, Jonathan Wilkes wrote: can set a boundary range within the slider. sort of like being able to select a range of a particular sample graphically. heres the max picture reference link: look at [pd edit] inside one of the helps for sliders .. [vslider-help] will do ... you can set the range of ordinary pd sliders via a message But the point is probably to get visual feedback for a range between two values, bounded within a min and max value. For that to work the indicator tick must be expandable while staying within the gui border. (Well, it does sometimes expand to 4 pixels wide right in the middle but that's a bug.) sure, the tick is not adjustable and if you want some visual feedback [cnv] will do the job ... here's another example, a bit more elaborate and all vanilla ... its mid summer here, way too hot for anything serious! here is another iteration, the end points and zoom adjustable plus some state saving ... just using sliders and canvases. open rangeslider.pd, it uses vrangeslider.pd Simon vrangeslider.pd Description: application/puredata rangeslider.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Range Slider Object
On 04/02/13 14:09, Jonathan Wilkes wrote: can set a boundary range within the slider. sort of like being able to select a range of a particular sample graphically. heres the max picture reference link: look at [pd edit] inside one of the helps for sliders .. [vslider-help] will do ... you can set the range of ordinary pd sliders via a message But the point is probably to get visual feedback for a range between two values, bounded within a min and max value. For that to work the indicator tick must be expandable while staying within the gui border. (Well, it does sometimes expand to 4 pixels wide right in the middle but that's a bug.) sure, the tick is not adjustable and if you want some visual feedback [cnv] will do the job ... here's another example, a bit more elaborate and all vanilla ... its mid summer here, way too hot for anything serious! Simon rangeslider.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Range Slider Object
On 04/02/13 09:11, Scott R. Looney wrote: well i'm pretty sure as a Max user i think he means an object in which you can set a boundary range within the slider. sort of like being able to select a range of a particular sample graphically. heres the max picture reference link: look at [pd edit] inside one of the helps for sliders .. [vslider-help] will do ... you can set the range of ordinary pd sliders via a message Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Working RPI Soundcards (was raspberry pi user experience)
On 01/02/13 21:22, Alexandre Torres Porres wrote: No, as nothing of current Pd can be hardware accelerated. A fast GPU would only provide a benefit for Gem. Therefore, you can improve the performance of GEM on a RPI with an external video card, cool. ??? I don't think you could add an external card in any way that could provide openGL. The built in GPU and its drivers don't provide openGL either, so no GEM at all on the RPI (unless GEM is ported to ES, or some GL to ES bridge is written). The GPU parts of the hardware are closed source, so no hacking the driver or such possible either. Same applies to Beagleboards and other similar devices as well, they all use ES rather than GL. Sticking to the Pi issue, since it is so economic in CPU power, what are the efficiency benefits from audio cards more than just number of inputs and outputs? They are needed on the Pi ... there is no analogue input and the built-in analogue out is very poor, hence you need some external USB card to do more than use the stereo digital audio part of the HDMI output. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Working RPI Soundcards (was raspberry pi user experience)
On 02/02/13 01:03, Alexandre Torres Porres wrote: pd and pd-gui are two separate processes and they run on separate cores, if there is more than one. That makes me wonder now hoe the [pd~] separates the processes between 2 cores then. I really thought PD was a single core processor that you could only split with [pd~]. [pd~] is for splitting the DSP part into separate threads in a closely synced way ... if you have clearly independent parts of your patch and you want to run it on several cores often it makes more sense to run a few instances of pd, passing information between them using the local network ports. Eg if you have GEM and audio parts this is often the way to go. Pd-gui essentially runs the interface, though I understand the separation between the two isn't as clean as it could be. Audio and message processing is done in pd. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [nbuntil]: an non-blocking [until] replacement
On 17/12/12 08:06, Jonathan Wilkes wrote: Why not just trigger each iteration with [bang~]? because with [bang~] you would get a single iteration per block, rather than as many iterations as you have time for ... which seems to be the intention of [nbuntil], and very useful where you might want to do a loop which may be too long for one cycle but you can wait and use the results when they are ready, after a few cycles perhaps. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
On 08/12/12 07:50, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. it would be better to use .pd_li386 or something like that, since it is good to be able to search for name.pd* in your filesystem to find the file for [name] without knowing if it is an abstraction or external. Given the way pd/extra is organised this is important, it is not at all obvious where to look. For example here on debian if I am missing an object in a patch I can find the packages that could supply it, and where they would put it ... $ apt-file search uzi.pd pd-cyclone: /usr/lib/pd/extra/cyclone/uzi.pd_linux pd-pmpd: /usr/lib/pd/extra/pmpd/examples/ch_uzi.pd pd-purepd: /usr/lib/pd/extra/purepd/uzi.pd .. or I could search locally in my files system to find which library the file is in. But this would not find uzi.l_ia64 and just searching for uzi finds 60 mostly irrelevant files which happen to have uzi somewhere in the name. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] rjdj is gone, robotcowboy is coming ...
On 02/11/12 11:04, Scott R. Looney wrote: i had heard that to be totally safe you needed to use MIT or BSD licensing on the external. has anyone found that to be generally true? To sell an app on the App Store you give apple a license to distribute it and they agree to give you 70% (or so) of what they sell each DRM locked copy for, the business model here is selling the right to use individual copies of binaries of Apps. The end user license that the App Store offers is the right to use a copy the App in a restricted way in exchange for a one-off payment. Any code that is Public Domain, or at least licensed so that there is no restriction on redistribution of the binaries is compatible with that model. Any code that requires the distributor to provide source code is not, Apple does not like that and will not do so. So if by 'safe' you mean compliant with the needs of Apples business model then giving them a license for code which is Pubic Domain is 'safe', as is giving them a license any code that can be redistributed as closed source binaries. Any copyleft license that restricts use of the code to open source projects only by requiring the distributor to provide the source code is 'unsafe'. It is unacceptable to Apple and will not fit in their App Store. I believe most GPL code is intentionally copyleft, the (original) developers actively did not want to give it away for use in closed source projects. Many are willing to sell their code to closed source projects with a different license, but of course each contributor must agree to the license given to Apple and many would want to be given a reasonable share of that 70% in exchange for the use of that code. If that 70% is actually $0 then they must be willing to allow closed source, DRM locked redistribution of their code without payment. That may well conflict with their own business model, they may consider this 'unsafe'. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] rjdj is gone, robotcowboy is coming ...
On 03/11/12 11:44, Scott R. Looney wrote: thanks for that excellent information Simon! very descriptive. i am partially wondering about this myself because there are a few developers out there using PD/libpd as a sound engine for games, and one obstacle encountered is that it is not possible to use pd-extended under libpd because of the issues copyleft/GPL presents when creating iOS apps. i am personally in favor of open source/copyleft myself, but it is a significant issue. i for one would love to see the cyclone library (both audio and data objects) ported under a different license - is this just a matter of recompiling from source independently, or should i get permission from the maintainer (i think it's HC, right?) to do so? If NONE of the original source you use is copyleft (and you do everything else yourself) it would be fine, though talking to the current maintainer is very appropriate and may save you wasting time ... you would need to check the licensing carefully, and a build system is already set up so it would be easy enough for them if they were willing to allow their own contributions to be distributed without a copyleft license. Debian policy is quite strict about redistributing the original source code with the original licenses intact and properly documented and since that is where it is maintained that information should all be there in pd-cyclone.deb, with the sources and Debian patches all in the Debian source repositories. The Debian maintainer has done all that work for you. If it is currently described as GPL then the sources are probably copyleft licensed and hence incompatible with the App Store. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Stream phone call to pd?
On 30/10/12 06:13, Johanna Nowak wrote: * Charles Henryczhe...@gmail.com [2012-10-29 21:12]: A software only solution is more interesting though--good luck, I have no clue how you might do it, but I'll be reading to know if/how you do. Has anyone already suggested a SIP software phone that can talk to jack (perhaps via one of the alsa bridges)? Asterisk can talk to jack directly, and is very capable. It can make and receive calls, generate voice menus, deal with SIP, SMS etc etc. I did a project using some of that capacity along with Pd a few years ago. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI and JACK autoconnection is a PITA...
On 30/10/12 06:12, Johanna Nowak wrote: Jörn, this is a quick shoot from the hips, perhaps it can help: * Jörn Nettingsmeiernetti...@stackingdwarves.net [2012-10-29 20:38]: is there a way to prevent pd from doing this? particularly in the alsa midi case, it's a really blatant misfeature, because in the presence of a software midi thru port, it will immediately create a parameter loop which will make any connected midi controller go wild and burn its motors. If this is the case for the BCF2000 try using its U-3 or S-3 mode, where it will not echo the received midi data to its outputs. The BCF2000 and the Pd sliders work very well together with feedback - not sure exactly which side does the work to allow the loopback to work well, but it does, it is possible to use those loops to give manual control from the BCF2000 at the same time as Pd sliders and calculated values are being used. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
On 04/10/12 15:54, Claude Heiland-Allen wrote: On 04/10/12 01:08, Simon Wise wrote: wouldn't that make it difficult to put the window outside the screen deliberately ... for example to hide the window decorations off-screen? I have needed to use this a few times (when making the window properly fullscreen was not possible or appropriate), and it is sometimes a lot easier than trying to work out how to tell a particular window manager not to put decorations on a particular window. 'devilspie' is what I use for generic window-manager-override tweaking, though I tested it myself with only xfce4 desktop. yes, I've generally worked it out locally on any linux machine I set up - and devilspie and xfce4 have been useful - but when working on a machine that is not mine to tweak so much, or on OSX in the past, it becomes much simpler to just set the window geometry so that the decorations are hidden off-screen. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
On 04/10/12 04:07, Hans-Christoph Steiner wrote: Sounds like this should actually be: set x [ expr max($x % $screenwidth - $::windowframex, 0)] set y [ expr max($y % $screenheight - $::windowframey, 0)] That would ensure that x and y are always= 0. Does changing that in pdtk_canvas.tcl solve your issue? The tricky part here is that this would then break how Pd strictly sets the position of existing patches based on the values on the first line of the patch file. wouldn't that make it difficult to put the window outside the screen deliberately ... for example to hide the window decorations off-screen? I have needed to use this a few times (when making the window properly fullscreen was not possible or appropriate), and it is sometimes a lot easier than trying to work out how to tell a particular window manager not to put decorations on a particular window. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd download page
On 30/09/12 05:40, Antonio Roberts wrote: This has also happened to me on a couple of occasions. They saw that it was for all platforms and so downloaded it, regardless of operating system ... and then they got puzzled, asked someone else, downloaded the proper one and learnt something about software in the process ... isn't that part of the reason you get students to download it themselves? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] arraysize WAS apt.puredata.info is back!
On 28/09/12 12:48, Jonathan Wilkes wrote: I'm referring to what Hans wrote: For me, apt-get install pd-arraysize is far easier than trying to remember that [expr] trick. And thankfully we can write externals, so we can have choice. :-) exactly ... Not exactly-- you were referring to using the Debian packaging system in a general sense to find packages, and you were saying that calling someone who uses it a mythical user is not inaccurate. no .. I was saying that debian users who treat their debian repository as an extension of their system and the first place to look for something they need to do are not mythical at all, that if you are familiar with the debian tools it is very quick and easy to find which package has a file or functionality you are looking for, and that not surprisingly some of these users are able and willing to do the extra bit of work to make things they find useful available in the way they find convenient. If some debian users find it convenient then it isn't obsolete and shouldn't be deprecated unless the maintainer is tired of keeping it there or it is becoming incompatible with other things in that system. A huge number of non-debian users also benefit from the work done in debian maintaining dependency information, documenting licensing and building for a variety of hardware platforms ... they benefit via developers using that information to set up the systems that are widely used. A few extra bits and pieces that are mainly useful to a few debian users isn't a problem. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] arraysize WAS apt.puredata.info is back!
On 29/09/12 00:57, Jonathan Wilkes wrote: So if you think the debian repos are the first place to look, then you would agree they are the first place I look for a file I am missing, so if someone referred to [arraysize] I'd check if I have it available by: $ apt-file search arraysize.pd pd-arraysize: /usr/lib/pd/extra/arraysize/arraysize.pd_linux $ then apt-get install pd-arraysize or apt-cache show pd-arraysize if I wanted to see a description or dependency info first. that arraysize should tell the user they can get the same functionality with expr which is already installed with pd-extended, pd-l2ork, and pd vanilla and therefore more modular, right? yes .. that info is useful to include - perhaps in the arraysize help file, perhaps in the package description, and your expr example in help is the right one in that context. It is your suggestion that arraysize be deprecated that I do not like. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] arraysize WAS apt.puredata.info is back!
On 28/09/12 03:23, Jonathan Wilkes wrote: And who is this mythical user that looks to the Debian repositories to figure out how to do something in a programming language? (Hm, I'm not getting audio output, let's open up Synaptic and search 20,000 mostly non-related packages for a solution...) they are at all not mythical, though not as numerous as those using apple, windows or a pre-assembled linux distribution. once you get to know apt-get, apt-file, apt-cache and friends those 20,000 packages and their contents are very accessible, very well indexed in many useful ways and searching is incredibly quick and powerful ... then installing the result is usually painless, with all dependencies taken care of by the packagers. Running sid rather than stable you get a quite recent set of libraries all in sync version-wise, and sources available, to compile your own packages. certainly not the typical pd user, but also certainly not a mythical one either, and since the work done for such a package is by one or other such user then that seems very reasonable to me. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] arraysize WAS apt.puredata.info is back!
On 28/09/12 11:38, Jonathan Wilkes wrote: - Original Message - From: Simon Wisesimonzw...@gmail.com And who is this mythical user that looks to the Debian repositories to figure out how to do something in a programming language? (Hm, I'm not getting audio output, let's open up Synaptic and search 20,000 mostly non-related packages for a solution...) they are at all not mythical, though not as numerous as those using apple, windows or a pre-assembled linux distribution. That's not what I'm talking about. I'm referring to what Hans wrote: For me, apt-get install pd-arraysize is far easier than trying to remember that [expr] trick. And thankfully we can write externals, so we can have choice. :-) exactly ... certainly not the typical pd user, but also certainly not a mythical one either, and since the work done for such a package is by one or other such user then that seems very reasonable to me. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Super computer made of legos and Raspberry Pi computers
On 17/09/12 07:41, Alexandre Torres Porres wrote: it's more powerful than the Pi, but seems rather expensive still. It's $150, which is not that much less than an iphone. And if you take all the phone cost/screen and etc so you get only a single board, it should be cheaper and more powerful. Oh, as for comparing the processing power of an iphone, I found a link where someone seems to have figured out what its except that the cost of phone hardware is also linked to the ongoing price the buyer will be paying for network access ... often rather high, and the network operators can and do cover part of the upfront cost then get all that back and more later. Those prices are not really comparable. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] finding objects ?
I can update vcf~ in the PDDP docs at some point, but aside from that what do you have in mind? Multi-dimensional indexing whose data can be easily referenced by multiple features (object search, auto-completion, maybe other) How will multiple dimensions help users find something that isn't there? exactly ... to find details of what is on your machine depends on how consistently those things you happen to have installed are documented ... and some people are making efforts to document a subset of what is available consistently, but even covering just what is in the extended archives is a huge, never ending job. to find what is available on the www you need to rely on google or similar, this list, the wiki etc ... depending where the author has mentioned it ... and details and documentation will never be consistent, so indexing that usefully is difficult. An effort to package a collection of useful objects in a consistent and indexed way has been happening in the debian repositories ... even if you don't use debian or one of its derivatives (even if you don't use linux) this is a useful, consistent resource with the sources, dependency information, descriptions and various interfaces and indexes for searching it, mirrored on fast mirrors all over the place, archived, built and tested (for linux) on lots of architectures and against lots of other software. That infrastructure would be impossible to maintain for Pd alone. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Communicating with Pd
On 03/09/12 17:30, Pierre Massat wrote: Dear List, I would like to know whether it is possible to communicate with an instance of Pd from a bash or a python script (things like sending control values to specific [receive] objects), or any other program actually. I guess I could look at pdsend and pdrecieve manpages Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] finding objects ?
On 03/09/12 18:11, Фывапр Олджэвич wrote: yes, I know about help patches, but as Processing and arduino has a list of all available commands and operators on a web-site (and it is douwnloadable) - it is easear to find objects and commands, which you don't know, but need. everything built-in is listed with the right-click on the background, that is all that is available without installing extra stuff everything you have installed should have help files, if the person who made them made help files and the package you used installed them if for example you use debian packages then help files are installed and the help browser will show you what you have, and you can look up what packages are available easily in the usual debian manner ... but that is just the ones somebody has done the work to package, it is a useful subset of what is available there cannot be a full list of everything anyone has ever made ... there cannot be a complete list of libraries available in any language there are some efforts to try and make long lists of what is out there, these have been mentioned ... they can never be complete though they can be very useful the number objects available 'out there' grows every day, some are useful, some may not be, this mailing list is a fairly good guide to some of that stuff Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best way of controlling 50 speakers with pd?
On 03/09/12 03:28, Iain Mott wrote: perhaps your speakers already have amplifiers - if not, i came across this link recently for cheap amps: http://reviews.cnet.com/amplifiers-preamps-processors/lepai-lp-2020a/4505-7871_7-35190789.html these are rather nice little stereo amps for a good price, I used then recently in a multi speaker project (but there 2 * firewire devices was enough channels), and one of them was able to use the clock of the other. http://www.dealextreme.com/p/vma2016-2-10w-audio-amplifier-evaluation-module-evm-board-44123 Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD on Playstation 3?
On 19/08/12 18:38, Filippo Beck Peccoz wrote: Hi all, Now my question: does anyone have practical experience with porting PD to PS3? Does it run smoothly? Is it easy to do so? Any thoughts are greatly appreciated :) there was a discussion back a few years regarding this ... the archives show these threads: http://lists.puredata.info/pipermail/pd-list/2007-11/056300.html http://lists.puredata.info/pipermail/pd-list/2007-07/052174.html http://lists.puredata.info/pipermail/pd-list/2007-12/058006.html that was 5 years ago of course, but it was ported and used at that time, in house by Sony at least ... but that port was not released (most of Pd vanilla is not copyleft or GPL ... but rather a more liberal license ... so keeping the port closed is OK by the license). Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD on Playstation 3?
On 19/08/12 22:44, Filippo Beck Peccoz wrote: ah, seems like not much has happened since then.. I'm pretty sure it is doable with lbpd (correct me if I am horribly wrong), but what would be great is to have someone show up saying I've done it and it works! so that I can convince our programmers to integrate PD ;) well, those threads make it clear that Mark did it, it works, and it has been used in at least one serious game and for a while at least was available internally in Sony. So it can be done. But that version is not available to use. Others have done a lot of open source work since, such as libpd, which may be useful. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] higher resolution screen capture
On 20/07/12 23:39, Dan Wilcox wrote: I'd use ImageMagick and batch it. sure ... but the first attempt at resizing resized the pixel image rather than using the vector information, and after a quick look at the man page and failed attempts to use -geometry and -size it was clear it would take some time to go through the options and find the right incantation to open a .ps file at a given resolution ... so I tried scribus, it did the job immediately and I sent the reply. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
