[ANN / Share] AHarker Externals – convolution / dynamic dsp and more

May 16, 2011 at 7:29am

[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:

http://www.alexanderjharker.co.uk/Software.html

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

#57148
May 16, 2011 at 7:42am

Well done! A number of them should become part of the standard distribution.

#204686
May 16, 2011 at 10:31am

great alex!
many thanks.
when you plan to have windows version? ( yes paria win user here :-) )

thanks again for your effort

a.

#204687
May 16, 2011 at 10:40am

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.

#204688
May 16, 2011 at 11:02am

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.

#204689
May 16, 2011 at 11:08am

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!

#204690
May 16, 2011 at 11:25am

wow, simply amazing !!

thank you so much for sharing these :)

#204691
May 16, 2011 at 12:52pm

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

#204692
May 16, 2011 at 6:37pm

Hey Alex,

Is there an ETA on a windows version of these externals?

Thanks,
Anthony

#204693
May 16, 2011 at 6:44pm

@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.

#204694
May 17, 2011 at 6:08pm

These are amazing, Alex, thank you.

#204695
May 18, 2011 at 10:32pm

Great work, Alex!

Thanks for sharing this extensive object set with the max community.

-Joshua

#204696
May 19, 2011 at 9:07am

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…

#204697
May 19, 2011 at 6:06pm

Awesome externals! Thank you for sharing, Alex.

@jvkr “A number of them should become part of the standard distribution. “

+1!

#204698
May 20, 2011 at 8:11am

Hi Alex.

Quite impressive, thank you very much!

aa

#204699
May 22, 2011 at 12:55am

Hi Alex,

Bravo! Thanks for sharing.

Ádám

#204700
Jul 4, 2011 at 2:33am

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

#204701
Jul 4, 2011 at 1:51pm

Hey Alex,

Any word on windows externals?

#204702
Jul 4, 2011 at 5:41pm

@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

#204703
Jul 4, 2011 at 7:12pm

Thanks Alex – This is a very impressive collection of tools. Well done.

#204704
Jul 25, 2011 at 11:56am

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

#204705
Jul 25, 2011 at 12:47pm

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.

#204706
Jul 25, 2011 at 1:15pm

Yep that works, thanks and sorry for the noise :p

#204707
Jul 25, 2011 at 2:47pm

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.

#204708
Jul 25, 2011 at 2:56pm

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.

#204709
Aug 19, 2011 at 12:02pm

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

– Pasted Max Patch, click to expand. –
#204710
Aug 19, 2011 at 12:15pm

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.

#204711
Aug 19, 2011 at 12:26pm

Cool, doing it via [play "buffername"] makes more sense anyway :)

#204712
Oct 20, 2011 at 5:24pm

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

#204713
Oct 21, 2011 at 1:42am

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.

#204714
Oct 21, 2011 at 12:59pm

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

#204715
Nov 9, 2011 at 3:24pm

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

#204716
Nov 9, 2011 at 10:31pm

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

#204717
Nov 10, 2011 at 12:46am

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.

#204718
Nov 10, 2011 at 4:28pm

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

#204719

You must be logged in to reply to this topic.