Thank you jersmi for your feedback and your kind words!
I never tested VS-305 with Audulus 4. The file format has changed from Audulus 3 and a project opened in Audulus 4 won’t be compatible anymore with Audulus 3. I’m not too sure about how it’s handled exactly, and in fear that my whole library would be “corrupted”, I never tried…
It sounds like there is a compatibility issue. It’s strange that you can activate some sounds by manually pressing the buttons and that you can see the leds using a midi keyboard, but no sound. Can you also hear the strings/human sections by manually clicking on the buttons? Each button is midi mapped to one key. If Audulus 4 handles this differently than Audulus 3 that could be the issue.
Ok, I’ll do some investigating. Audulus 3 files should work in Audulus 4, but yeah, not backwards compatible.
Yes, I get sounds when I press any assigned button. I see two instances of the keyboard node – one for triggering, one with freq output just connected to monitors, presumably used to get freq values. Besides that I don’t see where the patch is set up to receive midi note data from an external keyboard? Or ??
Ah, I see. Not used to that, perhaps then the midi assignments did not make the journey to Audulus 4 – you did say that already, after all. Thank you for your patience, I’ll keep trying.
Ps. digging around I did notice that the button for one of the bass priority notes (21) might be in toggle mode (the rest are triggers/momentary, as expected)?
If midi assignments for the trigger node are not in the near future, any reason why I couldn’t alter your patch to bypass midi assignments and filter notes from the keyboard hz/gate outputs? For ex., convert hz to midi note then (note==69) * gate, etc. Would that disrupt para/poly?
Yes If you manage to route every gates to each key that should work. I don’t think that it should mess the para/poly setting. I’m wondering why the midi assignment of the buttons has been deprecated in Audulus 4.
There’s no other midi input data information available in Audulus 4 (a new node?), something that would explain that change?
One thing though: you said you can see lights inside the module when pressing keys. What lights? Not the C1, C2, C3 etc…?
Ok, cool.
Lights – in the trigger submodule, from Key trig detector (not C1, C2, etc.).
Regarding Audulus 4 –
I submitted a github request for @Taylor to clarify yes/no for A4 trigger midi assignments, hopefully not deprecated, possible he just needs to add it back in.
I’ll wait and see what he says, then take an appropriate path for A4 best practices. If necessary I’ll try a rebuild of your patch. It would be worth it, this is a great project!
If a rebuild is in order, I’m thinking about the new A4 Spigot node (ala Pd) that can remove a signal path from the CPU load. For ex., thinking how keys are separated here, might be able to reduce load by not processing unused keys.
Another thing A4 does not have, at least at present, are A3’s lightweight (compiled) 1-pole LP/HP filters. At a glance it appears you use them a ton here, and as you know, without them means replacing them with something requiring unit delays, and that would hugely add to the load.
(For slewing, I think there’s a reasonable method that could replace that’s not too heavy – most basic LP/“leaky integrator”, expr with signal*x + prevR*(1-x) where x is amount of slew and prevR is the output of the expression directly connected (fed back) to the prevR input port.)
At any rate, being invested in A4 means I’m considering these issues. This patch alone might make a convincing case to bring back A3’s 1-pole “utility” filters.
Omg the 1-pole filter node has been removed! Yes that’s a basic tool that is needed very often. The instrument is already quite cpu intensive, I can’t imagine what it’s gonna be with the expression node instead, if that works…
How can you get any sound? The 1-pole filter node is used everywhere, especially the envelope generators and osc waveshaping.
Well, I think this is a great project, so we can at least bring these to @Taylor’s attention. At least the 1-pole filters work in A4, can be saved and reused.
Regarding that basic slew using the expression + feedback to itself, I found that little trick in an example Audulus patch, “Scattering - Time Travels”. It works well, has that analog-esque lowpass log/exp curve. I haven’t tried to properly scale freq/cutoff. Also, I’ve only used it as LP/slew, probably also good subtracting from audio to get high pass. Since A4 also does away with the feedback delay, I guess the technique forces z-1 processing, but it’s still about as lightweight as possible.
Also, if I rebuild your patch I’m hoping the Spigot node will help save resources.
Here are some one pole A3 designs for comparison. There’s a unit delay with feedback LP model, a biquad based LP and the built-in A3 node. The built-in is clearly the most efficient, followed by the bi-quad based design, with the unit delay model pretty far behind. I would hate to see the built-in node removed. biquad_one_pole_filters_dev V2.audulus (18.7 KB)
Perhaps I should join the beta too at some point to help in the rebuild process (the less the better, hopefully!), since I know how it should sound. Identifying bugs would be probably easier.
I couldn’t get sounds from Audulus 4 as I can’t find the virtual keyboard, but just had a little noodle about on Audulus 3, oh my goodness, this is beautiful, thank you so much for sharing this
). Thank you a lot for checking this out!