The Holy Grail ? (second reprise)

#21

It was actually quite hard to get a decent violin out of the Z1 anyway. The best I got out of it was some chinese sounding thing, allthough it was quite expressive. Still the WSA is much better at it. I included a lot of cello work in Zamisdat.

#22

you actually CAN edit the code of the MI modules, though only to a limited extend as it is based upon the header files, which of course, I'm not going to edit.
First thing to do is to make a copy of the module by saving it to you home-folder, so don't embed the module, but.go to "edit module" and hit "copy to library" without embedding it.
then you can edit the module that you've saved (though still, don't embed it but save it again after a modification.)

note though, that I only did two edits. the first edit I did was adding an "active" control, so I could add multiple MI oscillators to a single project without the need for them to run all the time while their not in use.
Second edit is to use an attribute to choose between the different oscillator modes, though not all the oscillators use the same code. eg. most of the drums, except cymbal, use the same code, same for most "physical modeling" oscillators.

Still, I think it should be possible to add modulation entries by looking at the header file and see what internal parameters the code is using, perhaps some of these can be modded by an "external" code.

ps. I haven't saved these modded MI modules to the community folder as I'm not sure whether I'm allowed to share these..

#23

Some MI code is in headers ... (including some moved by johannes) but much is not e.g. the bulk of clouds and elements is not in header files.

( but your not altering the MI code in this case, so it doesn't matter)

... and this is changing in the next release, headers and source code are all being rearranged.

If you just want to add inlets, and so MI code is unchanged , this is better to add to factory objects ( as I did with lmnts and clds recently.) , just fork the repo edit and send us a PR.

imo, generally as these factory objects are not mature it's better to improve these rather than spur off copies with minor changes which will likely be duplicated in time.

#24

Errrrrrrrrrrrr? Although I do seem to get the core of your thought it's all too much "local dialect" to me still. I'll order my Axoloti in a few days and get my own show sort of running. But please carry on in the mean time. Any flowers that wil grow from my crazy wishes will surely strengthen the platform AND the community, even if only by making poeple finetune such earlier work. Thanks!

#25

yeah sorry, its tricky here... axoloti is a really "broad church" with everyone with different goals, and different backgrounds (musicians, patchers, developers, hardware engineers, dsp coders), each have different perspectives on topics. so often topics take different twists and turns (we only 'lightly moderate').
I dont understand half the hardware category, but I still follow the topics, and learn a lot :slight_smile:

Its actually what I like about axoloti, its so many things to so many people...
though it can be hard to follow at times, especially at the beginning, and I suspect that can be frustrating for some, if they just want to know how to do X.

#26

Yup, that is also what attracts me to it. It promises to be an optimal mix of hardware stability and software versatility that even enables peoeple who are not part of the music instrument industry to implement their own insights and concepts. Just my sort of thing! My first impressions of the community are also very good. So it's Nerdistan alright! (said the other nerd). :slight_smile:

#27

Er guys. I have also been following the thread about the 8 voice sample player. I do not yet have an Axoloti so it is not possible for me to verify anything and of course that project is still rather early but am I to understand that Axoloti already has trouble running an 8 voice sample player only? To me that would imply that anything close to what I suggested (reminder: granular sample treatment + basic resonator modeling via a flexible delay setup + a closing subtractive stage) might just as well only be monophonic! Does that sound about right?

#28

Just started playing with polyphony myself, and while it can suck-up the processing power pretty quck, it really does depend on the objects themselves. Sometimes I'm shocked at how much CPU is used, other times I'm amazed at how little!

The more you play with it, the more you get an idea of how you're going to get around any processing limits. If you find the board simply can't handle it, there's always the possibility of running one through the other, and I think I read somewhere that the boards will be able to talk to each other digitally in a future update.

Look at it this way, forget about polyphony for a moment and just concentrate on having a single Axoloti board as a single physically-modeled voice. If you look at it that way, you gain a lot of processing power back because you're not having to concern yourself with the power required for polyphony. Then, when your patch is final, you could always play around and see how it handles the extra voices, see what you can get away with etc, it's a balancing act to an extent.

But yup, the polyphony you'll get will vary wildly. I don't think it's possible to estimate it with any reasonable precision, cause there's too many factors to consider.

#29

This is exactly what I was telling you before... axoloti is a 168mhz arm processor (see here) , not a PC with 3 ghz with 8 cores... but its also 60 euros.
on the flip size, it runs a real time OS, dedicated to one task only - your patch.

how many voices you get will be totally dependent on how much process you do... and also how well you implement it.
if you put the resonator per voice, it will consume considerably more cpu, than if you use one for the whole patch.
this is why you need to start small, build things up bit by bit, see how cpu your using, see where you can accept limits, see where you are willing to spend the cpu.

(the thread you mention, my initial look at the patch, it seemed sub-optimal, ive not looked at it since though - I'm sure others are helping improve it, but I personally dont have time to look at all patches/objects created by the community... gut feeling is 8 voices is a reasonable goal, but depends on what fx you do, which probably consumes more cpu)

this is the problem with 'high level thinking'... I can create a patch that will on paper do as you, but if it would meet you expectations.. Ive no idea.

I bought multiple axo boards from the outset, because I felt that with my expectations were high.... so I planned for having multiple voice boards, which would then feed into a dedicate board for 'global fx'

I dont think you should necessarily do the same, I think a more 'sane' route is to get one board, experiment with it, see what you can get from it, try each part of your 'patch' separate, see its cpu usage... then work out how many boards you would need... and then decide if thats what you want.

multiple boards, currently this can be done, using USB/analog outputs into a mixer... this works ok, once you are building your final setup, but its not ideal during development.
there is a plan to have digital audio between boards, but its early days... and by definition will create some latency. (though the good news is, with axo being so low latency, this extra, Id hope will not be an issue.
(though as always, buy for what it can do now... not what it might be able to do in the future!)

of course, I do accept one thing here... the cost of this project, will not really come down to hardware costs , even if you buy 5 boards (not saying you need this), its still what , 300 euro, which is 'cheap'

the real cost, is the investment of time... which, as Ive highlighted before, may be high, depending upon your skill set... and (again repeating myself) , I suspect, in practice, you will find it hard to 'sub contract' work... it may be your interests lie where others do in which case it will work out... but no-one can promise you this, no-one will commit to getting your project to work... they have their own to get on with.

#30

Hold Your horses, Technobear. Like I said before I am still getting my head around everything. What is already evident to you is still new for me and having pink cloud dreams before reality strikes is also part of the fun anyway. Or is that already too long ago for you? :slight_smile:

About combining multiple Axoloti's: If one compares the prices for low end polyphonic synhts the norm seems to be about Eu 100 per voice, although one then normally is inlcuding a complete hardware environment. By the way: Axoloti's cost more then Eu 60. Inlcuding VAT and shipping I got a quote of a bit more then Eu 90. Still a mulit-Axoloti would be reasonably priced indeed, considering all it's other advantages.

Putting them in series like Axoman suggets would obviously be a rather economic proposition anyway (for instance 1 Oxoloti for the granular sampler and a 2nd one for the rest) but when looped through via audio this will have a few distinct disadvantages. Increased latency for one but one would also no longer have a purely polyphonic system but a paraphonic one.

Would parallel in and out per voice however be possible via the hardware points?

To run more Axoloti's in parallel might indeed be th best option. A bit like the old Oberheim SEM system, where similar modules where controlled from one keyboard.

The biggest problem would however be the interfacing with the program. In that case it would at least have to be able to send live setups to more then one Axoloti from one single computer. Otherwise huge "wiresalad sessions" would be necessarry to get everyhting lined up.

I assume that you mean that this is not yet possible at this point?

About putting in my own share of work. That should not be a problem at all. Most of my projects run for years. Once I am commited I am a real tanacious B.. :slight_smile:

#31

Hi Marc, I just want to clarify what I meant.

I was not suggesting to use them in series other than a last resort really. This is why I recommend looking at each Axoloti as a single voice, as in, look at a single Axoloti as your processing limit per voice, don't look at it as a limitation of total polyphony.

If absolutely necessary, you just have to get extra boards per two, four, or eight voices etc.

#32

I connect multiple axoloti's to the same USB hub, so then i can just plug that one cable into the computer.
(I bought some very short usb cables, 20cm, to use to the hub to keep it tidy)
currently, the software can only talk to one axoloti at a time, but you can run multiple instances... not ideal, but works ok for me.

as for topology, Im going multiple voice axoloti(s) (either voice allocation or multiple timbral) into mixer, then sends into 'fx' axoloti(s).

the only audio output options are, digital (not available) and the stereo in/out... (afaik)

#33

your description reminds me of some tools from ircam software pack but I can't recall the name, it was part of the forum package. Maybe you could take a look at it!

#34

Hi Axoman,

I totally got that. It is actually not a bad solution at all as long as one is aware of those limitations. I've never looked down on paraphonics anyway. I did some of my best work on a Korg Mono / Poly. Paraphonicity (I just came up with that word, didn't I?) can for instance be great to use trigger and release timing in combination with some nifty EG settings to introduce expression and / or simulate velocity sensitivity into chord stuff.

So if chaining 2 would be the way to get around the processing power limitations one would have to expect for the sort of setup we have been discussing here I could live very well with it until. At least until I had the dough to buy enough Axolot's to set up a 6 or 8 voice fully parallel polyphonic "multitimbal" solution.

Basically that makes the inability to run multiple Axoloti's under one programming environment the only real limitation. Assuming nobody has yet come up with that point I'll toss it into the user interface discussion. Just to stoke up that fire as well.

To parahrase a remark Technobear made: Being a high level thinking wise ass is my speciality. :stuck_out_tongue_winking_eye:

By the way: Do manually switchable USB hubs with enough outputs for such a setup exist?

Marc

#35

IRCAM OpenMusic?

I gues it is a problem every flexible open architecture software will be confronted with sooner or later. There wil alwys be "freaks" who want to outdo the original inventors intentions.

Someone once argued that the Golden Age of electronic music actually ended when the capability of the tools became higher then the average users fantasy / insights. It was in "Pioneers Of Sound", a BBC documentary about the Radiophonic Workshop that I can thoroughly recommend!

#36

Hey you're not alone there, Mr Brassé, I'm a "high-level thinking wise-ass" myself you know :laughing:
Often much to the distress of low-level thinkers :grin:

Regards "the golden age of electronic music", well I say knobs to that one my friend, knobs!

knobs are the answer. I firmly believe that as the amount of knobs declined and "Preset Memories" became the norm, the quality of music started to go downhill as fast as originality did.

#37

High level thinker as well, eh? Poor you. Then you must indeed constantly be in trouble. With me it is so bad that people find it very difficult to work with me. The worst are the realy talentless who have developed their political skills to compensate for it. They hate my guts. Well, maybe I am just a wise-guy full stop but it is the best way I can integrate my remaimning selfesteem with what I always stir up. :sob:

Knobs are the best indeed. That is a big part of what Axoloti is, isn't it? It also brings back the knobs. I am so attracted to the total concept because you can, with or without the help of some others (as Technobear pointed out correctly you can indeed not force people to jump onto your specific bandwagon), for the first time you can build something that is your own concept or a sort of optimized variation of your preferred instrument and the even integrate it in your own hardware environment. I have never dared to hope for that posibility. To me that is actually much more attractive then building whole libraries of instrument patches, since I have always found it much more interesting to concentrate on a certain instrument / platform and the go as deep as I can in stead of just following fashion.

With platforms like Axoloti we can sort of move back to the good old times when building up a setup was a lot like building up a signature sound. That is also why I still insist on programming all of my sounds, except the few that I can simply not get better then the factory stuff. These used to be most of the standard acoustic instruments but even these presets are loosing ground since I have started to concentrate on modeling.

Anyway: Even if some limitations still exist the Axoloti concept is already spot on! :smile:

#38

What matters though, is that you pursue whatever you wish regardless. I've lost count of the times I wish I'd put the time in to learn C (and one day I might even do that), but I'm also very conscious of the fact that being a high-level thinker has advantages. It means I can concentrate on the high-level stuff such as good design.

Regards the hardware, knobs etc, I think you'll be impressed. It's a bit like having access to an endless supply of Eurorack modules. Sure, it's done in software, but the point is, Axoloti is independent hardware, so that's what really 'seals the deal' for me so to speak, there's no computer required for the end product.

It being open source is another attraction.

#39

That discussion you started up about graph type input "management" is very interesting. It is another part of what I already have in mind for this Holy Grail thing of mine but I thought I'd wait a bit to not confuse people even more. But since you have now brought something similar up already .... see my entries.

#40

Thanks for your replies there, Marc, and here's another one for you :yum:

On your travels, have you come across any especially good sites for physical modeling of instruments where they discuss the construction in a topological sense? Like, for example I've seen stuff where they discuss how to create the Karplus-Strong algorithm using modular gear. Are there any websites you know of that have a whole list of different models and how to create them using modular synthesizers?