Hi Tony, just put it on Github- hope I did everything right :) https://github.com/fbpsound/pip_abstractions . Will be working on the help patches this WE.
Thanks again for your input! Cheers, Filippo On Feb 19, 2014, at 4:36 PM, Tony Hillerson <[email protected]> wrote: > Filippo, you should put it up on Github. I can help if you need it... > > -- > Tony Hillerson > > On Tuesday, February 18, 2014 at 22:07 PM, [email protected] wrote: > >> Send Pd-list mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.puredata.info/listinfo/pd-list >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Pd-list digest..." >> Today's Topics: >> >> 1. Re: Game Audio abstractions- how to publish? (Joe White) >> 2. Re: Wich licence? (Mario Mey) >> 3. Re: libpd separating gui from core (Rich E) >> 4. Re: libpd separating gui from core (Jonathan Wilkes) >> 5. Re: libpd separating gui from core (Jonathan Wilkes) >> Forwarded message: >> >>> From: Joe White <[email protected]> >>> To: Filippo Beck Peccoz <[email protected]> >>> Cc: PD list <[email protected]> >>> Date: Tuesday, February 18, 2014 at 7:25:45 >>> Subject: Re: [PD] Game Audio abstractions- how to publish? >>> >>> Nice one Filippo! Thanks for sharing >>> >>> Cheers, >>> Joe >>> >>> >>> On 16 February 2014 21:31, Filippo Beck Peccoz <[email protected]> wrote: >>>> Hello list, >>>> >>>> I've collected and cleaned up a few patches that I've been using a lot >>>> while making game audio with PD (mainly for Android, using libpd, Unity >>>> and Kalimba) and wanted to make them available to everyone. >>>> Giving a tiny bit back since I've received so much help and advice from >>>> the PD community! >>>> >>>> I'm mainly trying to cover what a PD beginner/game audio composer would >>>> need in order to start building a PD-based audio engine for a video game. >>>> Threw in some mixer abstractions, some stuff for interactive music, a >>>> state-based drum machine and so on. >>>> >>>> As I said it's super basic, but it might just be less intimidating for >>>> someone who's just interested in the game audio potential of PD to have >>>> these basic blocks handy. >>>> >>>> Let me know if there is anything that can/should/must be improved in order >>>> for it to be of any use! I'd like to make help patches for the abstraction >>>> as well, but am not sure if they really need them since most of them are >>>> very simple. What do you think? >>>> >>>> https://fbpserver.dyndns.org/pydio/data/public/5b1c5c.php >>>> >>>> Cheers, >>>> >>>> >>>> Filippo >>>> >>>> >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >>> >>> >>> -- >>> Follow me on Twitter @diplojocus >> Forwarded message: >> >>> From: Mario Mey <[email protected]> >>> To: [email protected] >>> Date: Tuesday, February 18, 2014 at 12:54:03 >>> Subject: Re: [PD] Wich licence? >>> >>> Right, I put GPL license, I think it is the best for this project. I >>> uploaded it here: >>> >>> http://puredata.hurleur.com/viewtopic.php?pid=40358#p40358 >>> >>> You can see MEH-SYSTEM on stage and with full success, here: >>> https://www.youtube.com/watch?v=ckKg_rS5ezQ >>> >>> Thanks everybody! >>> >>> >>> >>> On 16/02/14 02:03, Jonathan Wilkes wrote: >>>> On 02/15/2014 03:14 PM, olm-e wrote: >>>>> On 15/02/14 20:53, [email protected] wrote: >>>>>> Date: Sat, 15 Feb 2014 16:52:58 -0300 >>>>>> From: Mario Mey <[email protected]> >>>>>> Subject: Re: [PD] Wich licence? >>>>>> To: [email protected] >>>>>> Message-ID: <[email protected]> >>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>>>> >>>>>> On 14/02/14 15:45, Jonathan Wilkes wrote: >>>>>>>> How would that be any different than spyware? >>>>>>>> >>>>>>>> -Jonathan >>>>>> Haha! Good point! >>>>>> >>>>>> Thanks everybody for the answers. I took a look to Matt Davey's DIY2 >>>>>> effects and he put no license txt file on its folder. Maelstorm mmb >>>>>> libraries have no license too... >>>>>> >>>>>> My patch is for everyone who wants to use it or learn with it. If >>>>>> someone finally uses MEH-SYSTEM or a modified version of it in stage or >>>>>> for a video or whatever... I "would like" to know it... only that! >>>>>> >>>>>> Maybe I leave it as is. Saying nothing about license... >>>> >>>> Skim the Wikipedia pages for GPL and 3-clause BSD, choose the one you >>>> prefer, and then you're done. >>>> >>>> Otherwise you create potential work for anyone who may have a use for >>>> your software to figure out what the terms of use and distribution >>>> are. It's probably not a big deal for a particular piece of software, >>>> and there are plenty of Pd patches out there that don't specify >>>> anything. But when you take, say, everything that exists on Github, >>>> the lack of licenses probably leads to busywork that eats up >>>> measurable amounts of time and effort. >>>> >>>> -Jonathan >>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>> Hello, >>>>> having no licence is probably not a good idea, as it's like enforcing >>>>> the default copyright rules that basically give no rights at all ... >>>>> (lots of code are practically not legaly usable on github for that >>>>> reason f.ex.) >>>>> the best would be IMHO to put it in (L)GPL and gently ask to downloaders >>>>> to report use as a courtesy on the download page... >>>>> have a good day, >>>>> >>>>> Ol. >>>>> >>>>> _______________________________________________ >>>>> [email protected] mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >> Forwarded message: >> >>> From: Rich E <[email protected]> >>> To: Dan Wilcox <[email protected]> >>> Cc: [email protected] List <[email protected]> >>> Date: Tuesday, February 18, 2014 at 21:11:41 >>> Subject: Re: [PD] libpd separating gui from core >>> >>> >>> >>> >>> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <[email protected]> wrote: >>> Ah wait, duh. Of course the graph needs to know positioning, that's how it >>> determines execution order or independent blocks of objects right? >>> >>> On Jan 13, 2014, at 5:14 PM, Dan Wilcox <[email protected]> wrote: >>> >>>> Does the dsp graph rely on positioning? I thought only via connections. >>>> I'd imagine the gui wrapper should only worry about positioning and simply >>>> update those changes when saving. >>> >>> >>> >>> IMO a separation between GUI and core could/would include position, e.g. >>> objects have their connections mapped by an index, GUI assigns the index to >>> the object based on position. This would allow for some much more >>> sophisticated GUI's, such as 3d, or even a more human-readable text version >>> (json has been mentioned). >>> >>> >>> cheers, >>> Rich >>> >> Forwarded message: >> >>> From: Jonathan Wilkes <[email protected]> >>> To: [email protected] >>> Date: Tuesday, February 18, 2014 at 21:23:01 >>> Subject: Re: [PD] libpd separating gui from core >>> >>> On 02/18/2014 04:00 AM, IOhannes m zmoelnig wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> On 2014-02-17 22:42, Jonathan Wilkes wrote: >>>>> No sane person is going to do incremental work without a plan on >>>>> GUI software in 2014 that only has a single undo. >>>> luckily the work on the GUI will most likely happen in git, which >>>> gives you infinite undo. >>> >>> The question is whether a highly capable dev who isn't already >>> entrenched in Pd development would see participation as worthwhile or a >>> waste of time. >>> >>> What I'm saying is that without a clear plan, no sane developer is going >>> to undertake the work of adding infinite undo, various GUI improvements, >>> or anything else that can't ship as an external. >>> >>> But yes, technically you can use Git to do yet another GUI rewrite if >>> you wish. >>> >>> -Jonathan >>> >>>> >>>> fmasdr >>>> IOhannes >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1 >>>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/ >>>> >>>> iQIcBAEBCAAGBQJTAyE4AAoJELZQGcR/ejb4p20P/0v4ZnEhRhzuLBzl3Jr8bGRC >>>> FSp04pTFlgdIqYPvJJooQA2vWJPHCOcHNPI7u8kDJk3tr+1p1EQ41apK6qFw/xU5 >>>> E1093htLiZojq2OCMMO9ZOYbm0DXZZHRmo6nMcG2GXceqCSNA3OMw7p4MRGyVJB1 >>>> tS/gyckHowInGDif+3eYKSD6iTZcBFpa/QahaT9kZzTk6HQ4hRtoro5OZ/z97nj6 >>>> ILJsDv0xK01I4MF1s9OUsMdVp6itTCI9irHYOMr1IeNbhQMaZrT1z2HtqG9q8NZs >>>> Q4p6uKGtGgqIZU5noCrmLnxVde0HlirpxSIDzq+FHJ4b9dQk9pJSI+zKTE8hCs1O >>>> sCUFZNi2udd9NwkaAqs1/2msf15WO+GmguMZXzaOiOxcx9FKrVE03IATZ4vqLNCd >>>> AucU9dxohcYrqPuzzBhfxmmYk6aLwPaZpamezTeBNCni0qn25X5ZwDWY6YHnd5fO >>>> Ck1yvhWKO0g5jVH2Tx4iAgnceKVqe++q5q+XnR8goFPFvxPC3THCGoGaIx4FSgea >>>> Zcfy3VymCWByyG57K2yV2R+wr3qwK8TDligtM0XoUB+a0caYr6uq5qMnOTzOJpIt >>>> GpwrWerw1957a/ccxpkNpofh4HPosg0oeYRajc1mELY07bLcahgMaIGxIevxvub2 >>>> 00RL1CEc36ySA5xLzcsd >>>> =M/8o >>>> -----END PGP SIGNATURE----- >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >> Forwarded message: >> >>> From: Jonathan Wilkes <[email protected]> >>> To: Rich E <[email protected]>, Dan Wilcox <[email protected]> >>> Cc: [email protected] List <[email protected]> >>> Date: Tuesday, February 18, 2014 at 22:07:20 >>> Subject: Re: [PD] libpd separating gui from core >>> >>> On 02/18/2014 11:11 PM, Rich E wrote: >>>> >>>> >>>> >>>> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <[email protected]> wrote: >>>>> Ah wait, duh. Of course the graph needs to know positioning, that's how >>>>> it determines execution order or independent blocks of objects right? >>>>> >>>>> On Jan 13, 2014, at 5:14 PM, Dan Wilcox <[email protected]> wrote: >>>>> >>>>>> Does the dsp graph rely on positioning? I thought only via connections. >>>>>> I'd imagine the gui wrapper should only worry about positioning and >>>>>> simply update those changes when saving. >>>>> >>>> >>>> >>>> IMO a separation between GUI and core could/would include position, e.g. >>>> objects have their connections mapped by an index, GUI assigns the index >>>> to the object based on position. This would allow for some much more >>>> sophisticated GUI's, such as 3d, or even a more human-readable text >>>> version (json has been mentioned). >>> >>> You run into problems when you want to get decent GUI interaction _and_ >>> expect to deliver audio to the soundcard in realtime. >>> >>> Actually even in 2d without audio the problems manifest themselves pretty >>> quickly. For example: open the svg tiger inside Inkscape and move it >>> around. Notice the clever trick-- the image is broken into tiles and moved >>> starting with the pieces closest to the mouse. Since the user's eye >>> focuses on the mouse pointer, the interaction looks snappy even though it >>> may take half a second or more to finish moving the tile furthest from the >>> pointer. >>> >>> When you add realtime audio the options are either to err on the side of >>> sluggishness or to be responsive and risk dropouts. If you want it to be >>> responsive in both video and audio then you have to start doing some >>> serious optimizations based on what you think the user cases are for the >>> software. For example, the Inkscape trick is perfect for creating and >>> manipulating vector graphics, but it would be terrible for a 2d animation >>> environment where you'd presumably want the tiger to move as a single unit. >>> >>> However, many of Pd's current problems don't have a lot to do with that. >>> Tk is pretty good at being sluggish and avoiding dropouts when it doesn't >>> have idle time to do graphics updates. In fact I can move around an svg >>> tiger on a canvas without interrupting the "test audio" patch. Most >>> dropouts related to the GUI have to do with what amounts to a DDOS attack >>> from the core to the GUI. When you flood tcl with data from the socket it >>> can't really do anything else but spend time receiving it. When you add >>> that to whatever Pd core is doing to generate all those messages in the >>> first place, you probably won't have any time left over for delivering >>> audio. >>> >>> Other toolkits are certainly more efficient than Tk. But if you're >>> dragging an antialiased wire from the top left of the window to the >>> bottom-right, the toolkit needs time to do those redraws. >>> >>> Finally, I'm not really sure how Open-GL and hardware acceleration plays >>> into all this. For example, Qt Graphics View docs have a note about >>> accelerated graphics possibly adding a performance hit and possibly more >>> latency, but it's only in the context of hardware that doesn't do floating >>> point computations efficiently. I played around with Kivy a bit, which is >>> hardware accelerated but honestly didn't see much of an improvement in cpu >>> usage over comparable stuff in Tkpath. >>> >>> -Jonathan >>> >>>> >>>> >>>> cheers, >>>> Rich >>>> >>> >> _______________________________________________ >> Pd-list mailing list >> [email protected] >> to manage your subscription (including un-subscription) see >> http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
