The Holy Grail ? (second reprise)

#4

sirsicsic = @SirSickSik

@brasso , As a mod, can I ask next time you don't cross post, just ask me to move your topic if you believe it's in the wrong category.

#5

@thetechnobear you meant @brasso, didn't you??

#6

Yes... I tagged SSS because @brasso wanted the correct username
( I've my post clearer now, just in case )

To be tidy :slight_smile: here is original post, which I will close

https://sebiik.github.io/community.axoloti.com.backup/t/the-holy-grail?source_topic_id=2996
#7

well, the loading of wavs is, as far as I know, still a problem. At least my axoloti crashes after using the wav-modules live..
Furthermore, the resonator-timings will ask a lot of actual, physical research of recording impulse-responses, which is a problem as I lack the right recording equipment (way too much noise at this moment) and time (I still need to work fulltime)..
Next to this, I wonder whether axoloti can handle the amount of taps needed to make a good response. We'll probably hit the ceiling on either CPU or sram.

I think the best idea is to just use the elements modules (osc/MI) and try to come close

#8

Yeah, sorry for that. They call it enthusiasm. Hopefully it catches on a bit. If you think Software is the right catagory just leave it here and delete / close the other 2.

#9

No problem... its just not necessary, I think you'll find most users are using the 'latest post' view, so will see posts across all categories. (Ive closed the previous one. and deleted the challenges one, as it had no replies on it)

this was my suggestion in the previous version of this post.

can I just make one small point on the MI objects/modules that i created.

Id recommend for this release to use 'as is', and let me know if there are any minor(*) changes needed,
(*) I dont have much time for doing anything other than bug fixes though.
I would not recommend others creating variations for two reasons:

a) you can't edit the MI code, as its in the firmware - so this means theres not much you can do, over whats already exposed. (see this thread for more details)

b) Im hoping/planning for the next release to remove the MI code from the firmware, to remove the above restriction.
this WILL break any objects which try to use MI code.
of course, I will fix this for the my factory objects, so user's patches using these will not be affected - but I cannot make any guarantees that 'derivative objects' will be easy to fix... the MI code base will be different, by how much I cant say at the moment, but obviously want to keep my options open.

so, please experiment/play with these objects in 1.0.12 and provide feedback, its all useful... but just wait till the next release to create derivatives (where it will be much easer/controlled, assuming my current experiments work :wink:)

#10

Dear Sirsicksic et all,

1) Having looked at how the first hardware generation did it (see my previous mail) I also came to a similar thought: Having a whole library of responses is actually not that important because sampling libraries seem to have won the emulation wars anyway. My thing is more to add a maximum of expression and a certain acoustic quality to "fantasy instruments".
In that case one can patch a relatively simple but flexible triggered delay setup between the oscillator section and the subtractive section. I should have thought of that right away but I gues I still have to get accustomed to the openess of this system. And, er, I'll also look at those OSC/Mi's you mention.

2) I saw some modeling oscillators have also been put in the object list already. Cool!

3) But what about the granular sampler? I already reacted to this Youtube vid by Mathew Tyas: https://www.youtube.com/watch?v=VxMsG1UFpQ4 where he seems to use something similar but then only controlled in pitch by a pot. Or am I mistaking a relativley simple sampling delay setup for a granulator? Anyway: How difficult will it be to implement a basic granular sampler? Say one with a looppoint, variable grain length and variable cross fading (to go from intentional stuttering to more smooth stuff)? I assume a sort of wavetable-scanning solution would fit the bill?

3) About the sample format: Do I remember right reading that RAR's will do the job and that they can be made out of WAV's by Audacity anyway?

5) This early in the audio chain flexibility and character are much more important then high audio resolution. 8 Bit samples often have more character then 16 bits anyway. So maybe that is another way to preserve processor power?

5) Working with a line-input, like Matthew Tyas does, would already be very intuitive. I personally would actually find it even more important then sample import. Just rub an orange while holding a mike beside it and off you go! :slight_smile:

5) Since I have spent a "helluvoloti" of work on building special isomorphic Janko convertors for my MIDI keyboards (see teaser here: https://www.youtube.com/watch?v=4k_l88AXu2I) and poly aftertouch is very important to me anyway the next question is: Can an Axoloti instrument process poly aftertouch data received via MIDI?

6) Putting all that into one practical frying pan: Do the experts think that such a "reduced" but stable 6 to 8-voice "physical modeling" instrument per Axoloti would be feasible?

Marc

#11

OK I just tried to look osc/MI up myself but could not find anyhting. So information overload! What the hell is a osc/MI and where can I orient myself on the subject? :slight_smile:

#12

Hi, thanks for watching my videos

That granular patch is actually one of the most loved patches when people pay around with my different boxes, and it gets a few questions on youtube too.
The patch in question is just a very small adaptation of @johannes patch that he has in the community patch folder called : grainy-table (axoloti-contrib\patches\jt\grainy-table.axp)
The pitch input responds very well to a keyboard pitch too and can even be polyphonic. You can use it with input or pre-recorded materials.
When you open up the patch, you realize how simple it is actually, and adjusting it to whatever you want not too difficult.
and it uses very little CPU too :slight_smile:

#13

this thread has some discussion, but unless you have the patcher software installed (and really an axoloti board to play with it) , your lacking quite a lot of context.

fyi, MI = Mutable Instruments (not sure what the osc referred to :wink:)
as I mentioned on the other thread, I think you main interest is elements, and possibly clouds....
you can find more info on these here : http://mutable-instruments.net

unlike the eurorack module, some parts of these modules are available separate e.g. tube/string/diffuser... and of course then there are reverbs/choruses/delays lines etc

as i said before though, this is easier to experiment with rather than talk about... axoloti has most of the parts that you talk about, but if they are sufficient for your needs only you will be able to tell.

yes, axoloti can deal with poly aftertouch, it can also deal with MPE which is what I use with my Eigenharps and Soundplane.

#14

Thanks Matthew,

If it works like a granulator type polyphonic sampler indeed it is about the last link I was looking for. Together with thetechnobears next post about polyphonic aftertouch this answers my most pressing questions for the moment.

Is it alright if I sooner or later pump you for your experiences with hardware interfacing solutions?

Marc

#15

Hi Technobear.

Ah yes, the penny drops. I already saw a lot of interesting Mutable Instruments derived objects, among them the modeled oscillators I already mentioned. Is this because Mutable Instruments also runs on open source code or is it more a special courtesy of its developers?

So the next step for me should indeed be to get my feet wet and learn the propper dialect before I put in more stupid questions. Here in the Netherlands they do however say: "1 fool can ask more then 10 wise men can answer" so you might in the end still regret giving this advice! :slight_smile:

Marc

#16

Wow, i just heard the Mutable Instruments Braids general Soundcloud demo and my jaw has now firmly hit the floor. All this is already present within Axoloti as it is? The posibilities are mindboggling!

Marc

#17

@brasso
Yes, those MI objects add a lot of ulility to Axoloti, they're great objects (and fun). They remind me of the KORG Z1, I used to own one back when they were new.

Anyway, just wanted to say I'm enjoying the article I downloaded from your website, about the CS80. About a quarter the way though so far I think, and will read some more tonight.

Was interesting to hear of it's ancestry to the GX1 as well.

#18

I used the Korg Z1 for some time as well but found it's models a bit too restricting. You are simply pushed into a certain environment and it can be difficult to make a blown wood model or whatever sound like anything else. So fantasy instruments are hard to create. That is why I love the Technics WSA1 so much. It might not add specific response artefacts like overblowing because it works with an "impulse / exiter" sample pool but everything is freely interchangeable which makes it very flexible. Since I have gotten around to using it my benchmark when encountering something else has always been: Can it do stuff that my WSA cannot? Most of the time the answer was / is NO, however esoteric or beguiling the other instruments might seem to be. The only thign one can not do is load ones own samples inot it. If I could find a way around that problem I would probably still not switch to anything else. Can there be higher praise for an instrument, especially for one that is almost 30 years old? For more see my Starship One project. By the way: A major update of the INSTRUMENT and WRITING sections is presently underway so press control R regularly.

#19

It's great that you like my CS80 article. Do also read the one about the Son Of GX project. A second part is about to be added. You'll be surprized how much commonality there actually was within the Yamaha range. Most of us might see organs as a different, inferior species (I certainly used to think so) but Yamaha surely didn't.

#20

The WSA1 does sound pretty incredible, and I already have downloaded that album you mentioned, I chose to download the original version over the remastered version. Have listened to two of the tracks so far, was listening to them while browsing this forum!

I will indeed read the other stuff you mention :relaxed:

Regards the KORG Z1, I can't remember exactly what it was that frustrated me about it, but what you said would sound about right I think. If I recall, they marketed it as a sort of synthesists dream toolbox, and it was really for string type instruments I bought it, I wanted really nice violins etc, but it didn't satisfy, not in the way I specifically wanted it to anyway. I realised a few things over the years after I sold it, so my frustration with it might even be unfounded for all I know, but yes, I do remember feeling restricted by it in ways I would never expect from such a synthesizer, so it was probably the models themselves.

Was certainly a nice sythesizer though, no doubt about that!

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