[ANN / Share] AHarker Externals - convolution / dynamic dsp and more
I'm pleased to announce the public release of a large number of (currently Mac only) externals I've been working out for the last few years. I hope people will find them to be of use.
The externals can be found here:
These externals can be used freely for non-commercial use. I hope that at a later date I will be able to license them for free usage whatever the purpose but this is not currently possible. See the included license for more details.
The externals have been extensively used and tested (including by a crack international team of MaxMSP power users - you know who you are - and thanks!) - so there are as far as I know highly stable and ready for use.
Here's what you'll find there:
A Set of 80+ Externals for a variety of tasks in MaxMSP.
Mac OSX only (Windows versions and source to follow).
A brief overview of some areas addressed:
Efficient buffer playback and storage
General purpose scaling for Max and MSP
Efficient partitioned + non- partioned convolution
Enhanced audio multi-threading / dynamic patch loading
Comprehensive descriptor analysis (realtime + non-rrealtime)
Improved wiiremote communication object
High quality random number generators for Max and MSP
Sample accurate voice management and more
Thread debugging and switching
Utility objects
SIMD versions of 35 basic MSP objects
Do feel free to email with comments and questions.
Alex Harker
Well done! A number of them should become part of the standard distribution.
great alex!
many thanks.
when you plan to have windows version? ( yes paria win user here :-) )
thanks again for your effort
a.
I plan to go to windows as soon as possible. I have circumvented the main dependency already (apple FFTs), but not compiled anything under windows yet. Probably some of the vector objects (trigonometric functions etc.) and the wiimote object and maybe a couple of others, will never make it to windows because they have apple dependencies which would take too long to replace (writing my own SIMD trig functions seems like it might not be that much fun).
So - I'd hope to start rolling stuff out into beta within the next month, but we'll see how I go grappling with the beast that is Microsoft...
A.
cool alex!
for trig functions can't you use math.h?
or i've done a quick search and found this
http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/cpp/lin/optaps/common/optaps_vec_par.htm
i think there is some intel libraries for vector SIMD stuff
thanks again and all the best!
i'll be happy to test your stuff
a.
Hey Alfonso,
Thanks for this. math.h is as I understand normally non-vectorised - however, looks like intel provide some of the trig stuff (but possibly not all at a a quick glance). I will definitely investigate this and which machines it might work on - I had no idea this existed.
A.
@jvkr - Thanks!
wow, simply amazing !!
thank you so much for sharing these :)
Hey Alex,
math.h is scalar, not vectorial.
I worked with some extra paid Intel vector stuff on mach'o and it was great, when 'we' (software authors) were translating C/C++ into SSE.
(Seems that all or part of that has been included in/with Xcode.)
Well, try from: http://software.intel.com/en-us/intel-sdp-home/
Some feeds could come back from the Apple's Coreaudio-api mailing list @ http://www.lists.apple.com/mailman/listinfo
Cheerio,
Phil
Hey Alex,
Is there an ETA on a windows version of these externals?
Thanks,
Anthony
@Anthony - please see above in the thread. I am waiting on some dev tools - until then nothing can start. As for a final release date I'm afraid I won't be held to anything as I have to fit this with newer work. I would like to turn this around ASAP, but it is hard to foresee the exact number of issues I will come across, as there are several unknowns for me on Windows. Some of my code may compile directly, but I know some will not. There are also code blocks to add - for instance on mac osx SSE2 is an assumption of the system - under windows I will need to test for it explicitly at runtime - that's not something I know haow to do yet..... You get the idea. Work will start soon and I'll keep people updated. I may well look for testers, as I'll be running mac hardware for development, rather than a "real" windows box.
Great work, Alex!
Thanks for sharing this extensive object set with the max community.
-Joshua
this is really good!!!
for us the dynamicdsp objects are more than welcome since they help overcoming various weird problems we had with poly~ and it is more efficient for more complex routing situations.
the ibuffer system will help reduce our memory load
also the optimized standard objects give us a significant extra dsp 'headroom'
and much more...
Awesome externals! Thank you for sharing, Alex.
@jvkr "A number of them should become part of the standard distribution. "
+1!
Hi Alex.
Quite impressive, thank you very much!
aa
Hi Alex,
Bravo! Thanks for sharing.
Ádám
A question for Alex--
using the dynamic.patch object, does this mean it's possible to have this in a collective or standalone and then dynamically load patchers that are not part of the collective?
If so this could be handy in situations where you are using a Max run-time or standalone to have a 'master' run-time patch which loads other patches without having to make them into collectives first. And would communication between sends and receives work in this situation?
T
Hey Alex,
Any word on windows externals?
@Terry McDermot
Using the dynamicdsp~ or dynamicserial~ object you should be able to load patchers not part of the collective as long as you provide a path that max is generally happy with.
Sends and receives should just work fine however patches are loaded asfaik.
@ Anthony Palomba (and any other windows guys who are prepared to test) - please contact me offlist - I have some stuff to test, but no feedback yet from my main tester list - hence no release yet.
Thanks,
Alex
Thanks Alex - This is a very impressive collection of tools. Well done.
Hi Alex, I'm just starting to delve into this excellent collection!
Question:
Is it possible to allow the [recursivefolder] object to filter its output to .flac files via a [types FLAC] message?
What I mean is, it's not possible now, so would it be possible for you to add that feature?
cheers
The types message is the same as the one for folder, so it relies on the max types as set in the text file in the c74 folder. So, if you want to fix this I believe you can do it yourself.
The file you want to look at is:
max-fileformats.txt
in the init folder. This will also affect other objects using file types...
A.
Yep that works, thanks and sorry for the noise :p
Hi Alex, don't know if you're still working on the Windows detection bits, but the ICST lib has got SIMD optimizations for both Mac and Windows and might be helpful as a guide. My recollection is that the defines were pretty simple.
Hi Peter,
Actually I have compiles for most things working now, just lacking testers / time to finish that work up.
I'll try to check out the ICST lib if I get a chance...
A.
I've got a 100% reproducible crash with [ibufplayer~ ] - posting here rather than emailing so that other people can try and repro.
It's a little strange ...
OSX 10.6.8 Max 5.1.8
Thanks Tim,
I've been a bad programmer and not done my error checking properly...
Anyway, nice clear patch - I saw it within a couple of minutes in the source. This object also has some more important interpolation issues that I have cleared up here when working with non max buffers . I also have a few other bits and pieces / help file fixes to do and to roll out soon - hopefully along with a windows release.
In the meantime, do not send a play message with no arguments to ibufplayer~. It is just chance if it works. Instead send play buffername - that is safe....
A.
Cool, doing it via [play "buffername"] makes more sense anyway :)
Hey Alex,
I only now got to investigating your package of externals - on behalf of the community: thanks! Very impressive!
The reason I started looking into your package was that I'm trying to get a serious hold on faster-than-realtime audio analysis and your descriptors~ object seems perfect for the job, although daunting with all it's possibilities.
So I've been going through the documentation for the past couple of hours and started to get results but if you have a minute I wonder if you could give me some more pointers on how to use it.
For example, if I were to want to "paint a graph" - figuratively speaking - of the spectral centroid throughout a buffer what could be some ways to go about it? I.e. some ways to limit the data in a sensible way, I guess.
Or if I were to want to find all the positions throughout a buffer where a pitch is detected with a certain amount of confidence?
I know these are kind of vague questions but if you have the time to give any old example I appreciate it greatly and will certainly find my way further.
Thanks so much!
Best regards,
antwan
To look at a parameter over time you should analyse different chunks of the buffer separately for centroid and then figure out how to make a list of values (e.g. [zl group] perhaps). As it says in the help file, with the analyse message "you can optionally specify channel / start point (ms) / end point (ms)". You should probably first get the lenght of the file and from that figure out how many chunks, and the start/end points for each, depending on the granularity you want - remember to take into account your FFT/window size - don't set chunks smaller than the window - and you may well want them bigger. You can let the chunks overlap or not, as you see more suitable...
The second scenario is a little harder if you really want *all* the points. I think you need to do a threshold search on the confidence descriptor, but there will be a limit to how many points you will ever get back. I'm not sure off the top of my head what the limit is - it might be several thousand though.... look in the statistical_calculations subpatch at the fourth umenu down to learn more...
I hope that helps. I'm away form the UK at the mo, but if you are still having trouble by next week maybe send an email offlist?
A.
Hi Alex,
That will most certainly get me going.
As you proposed - I'll get back to you later if I get stuck.
Thanks so much.
a
Hi again,
This time I'm having lots of good times getting to know the dynamicdsp-objects. One big question I've come across though is:
- Is there any way to automatically or manually include pattr-objects within a dynamicdsp patch to a pattrstorage in it's parent-patch?
More specifically - according to the psto window - my pattrstorage does see the pattr-objects within the dynamically loaded dynamicdsp patch but fails to see or store any data from those pattr-objects. Is there something I'm missing, or is this simply a technical impossibility, or is this something that isn't implemented?
Thanks for any insights.
antwan
I've not tried pattr within dynamicdsp~ so I can't answer the question specifically, but one workaround is to make your dynamicdsp~ patches in two parts - an audio 'core' which is loaded into dynamicdsp~, and an gui patch which communicates with the core via send/receive or patch cords. Anything you need to expose to pattr can live in the gui patch.
This is the approach I'm using in my soon-to-be-shared 'Evil Tonelab' modular patch.
I'm using scripting to load and connect the two parts together. Data is then sent from the gui to the core via a single patch cord, using pack/route to sort the different data streams, but it could just as well be via multiple patch cords or send/receive pairs,
cheers
Roger
dynamicdsp~ knows nothing about pattr.
I suspect it could do, but it might involve asking one of the nice cycling people (maybe Jeremy Bernstein) how this should be done.
One question - does this work within poly~? If so then it's defo possible, but I do not as yet know how. I'll see what I can do....
A.
Hi!
@Alex
Yeah, checked & double-checked: it works as expected with polys and dynamic polys. The pattrs appear and disappear in the psto-window with the loadings and deletings of a poly patch. The data is also visible and storable. With dynamicdsp~ or dynamicserial~ I have to message the psto with "subscribemode 0" to them to appear in the window but, as I mentioned, can't see/access the data.
Would be wonderful if you find out how to implement that, keep us posted.
@Roger
Cheers for the workaround. Id love to stick with the pattr family for this communication but we'll see how the situation develops. I might very well use your idea meanwhile.
Thanks to you both!
antwan
Hello everyone
How can I access the help of external objects in max msp 7? Or how to load these objects?