randy's Recent Posts
It's coming, but as part of a more ambitious project, so it's going to be a while still.
Hi Timm, I hope you got my email. Sorry about the server burp last time!
if we didn't sort this out, please email support@madronalabs.com and I can help!
Hi nice person, thanks for the good words. I get the idea of a Kaivo audio input. When I eventually come out with a modular environment it will allow combining, say, Virta's input module with Kaivo's physical models.
Kaivo's granulator can't currently do anything with live input, because it is designed to analyze sound clips and find the best grain transition points ahead of time. So it's not as useful to have audio input for Kaivo, I think.
I was making a little music with Aalto over the holidays. I was trying to set up a flow where I could just tweak the knobs while recording audio out of Aalto, and record a lot of tracks that I would just mix together to get the finished piece. But, as you may have found, this is easier said than done! I have ideas on how to make things better.
Tweaking while recording
One problem is that the main DAWs don't let you record audio while tweaking knobs of a synth or effect. Logic has a real time bounce, for example, but locks out control changes while it's going on. Live won't record audio out of a synth unless you are in render mode.
One workaround is to use Numerology from Five12. It's great for on-the-fly sequencing and tweaking, and will let you record audio while you do this. It's a little less than ideal in that the audio is all sent to automatically-named files that you have to sort out later. But in even allowing recording while tweaking it offers a cool feature that the big DAWs don't. The drawback for me is that it's not the environment I want to mix in.
I checked out Reaper and did not get far enough to decide whether this would be a good solution for live recording. I could deal with learning to mix in it if it offered this capability. Anyone tried this in Reaper?
Finally, one solution might be a simple record button in Aalto. But I try to avoid adding things that the DAW should be doing well. Anyone up for writing a DAW this year with Live’s ease-of-use and timing, Logic’s MIDI implementation and Reaper’s efficiency?
Resetting
Another problem with the flow as it stands is resetting Aalto back to a patch at the start of a loop or arrangement. I'd like to set up one patch, do a take of knob-tweaking, and then automatically have Aalto recall a previous patch or saved state back at the beginning to set up the same jumping-off point for exploration. This is a little difficult now.
One way to do it, currently, is using MIDI program automation. Aalto 1.3 added the ability (underdocumented, currently) to switch programs via MIDI program change messages. See here for details. So, you can make a patch, save it to the "MIDI Programs" directory, and record a program change message in your DAW of choice. This is fairly easy in Logic, and in Live looks clunky but possible. There's an extra step of saving a patch, though, every time you want to define a new starting point. Not ideal. Maybe I don't care about the patch in general but just as an element in one song.
Resetting the patch is also needed to make the flow sort-of-good in programs like Live and Logic that don't allow control changes. An offline bounce (much faster than real time) after each tweaking pass may not be a bad price to pay for recording in my environment of choice, and so I can simply record the parameter change data---but the reset is also essential here.
There are a few ideas I have for a solution. One is to add a menu choice "broadcast all parameters." This would do what it says, allowing parameter automation systems to capture the entire state of the plugin. I think that with more than 100 parameters, though, this might overwhelm the capabilities of the DAW, and would certainly make a mess of the param menus.
A refinement of that idea is to have two menu options, one to say "start keeping track of what parameters I changed," and another to reset only those changed parameters. This would definitely work, the only drawback is a little added complexity. You would still need to be careful to save your song with all the params at their initial states!
I'm happy that Aalto 1.3.1 is very solid after the 1.3 shakeup, and I'm looking forward to working on some of these workflow details now. I welcome your suggestions!
I'll do a little something this winter.
Ach, OK, I found the problem. Not what I guessed above. Something else I optimized broke the sorting, but rarely enough that it did not show up in testing. This will be fixed for release soon.
Some of these patches require certain granulator waveforms from outside Kaivo, maybe that is the problem?
this works OK for me with the beta and all my factory patches. Do your factory patches sort OK?
In each patch there is a name stored with it that might be different from the name of the file. My guess is that they are being sorted by the internal names. If these get out of sync the sorting would be wrong. In the case of getting the patches from the forum these are likely not matching. I'll fix this somehow in the next version and for now you can change those internal names with a text editor.
Thank you. Sorting was implemented from the beginning, but for some reason broke in the most recent version. I'm working to get an update out.
OK. This is similar to a problem another person had on Windows.
I take then, that you're not using sym links to refer to any of the plugins or license directory?
I have not been able to reproduce this on Windows but I'll review the code and see what i can see.
Thanks for the report.
When you hear the hissing sound, look in the registration area. Do you see you registered name there, or "DEMO"?
Are you using a symbolic link to manage any of your related files? There may be a problem following the link on Windows sometimes. If this is the case, please describe what you are linking to and how.
Things have settled down. All the new work is in the "embedded" branch however. I need to merge to master, and also clean up the cmake and build instructions. Since there are not too many modules, it should be fairly simple to pull from the embedded branch and integrate with your own code in the meantime.
I made big changes to support the embedded work, but the work has not been done on the embedded system yet. The driver API is much more C-like now. it doesn't rely on a listener class and should be usable even in a single threaded environment. Let me know if you have any questions...
Thanks. Sample size is very small, but so far the people having issues are on 10.10.5, and it's working for everyone on 10.12.x.
I am deploying the app for 10.9 and up, so running 10.10 shouldn't be a problem. But maybe it is for some reason. If you think of anything let me know!
NOTE: two people so far have run into an issue where after trashing the prefs and running, the new version starts to select carrier frequencies, then hangs at 0%.
Please be advised that this bug exists, so you may want to hold off on version 1.5.0 if you can't spare the time to possibly revert. If you do have time to install and try it out, please let me know your results and the OS you are running.
No offense taken! I get it.
Hiya,
Thanks for your feedback. I'd like to find a way to make back + forth easier in Ableton as you say. The thing that's a little difficult about drag & drop is that Kaivo only "allows" sounds to be around 8 seconds long. It breaks the normal flow of drag & drop if the whole thing is not used and you need another step to select part of the file after dropping somehow. So I have not really come up with a good way for drag&drop to work.
It could maybe just import the whole thing if under 8 secs, then put up a little dialog "would you like to clip?" otherwise.
The short-file limitation is because files have to be scanned to find all the best grain crossfade points and I don't want that startup to take forever. I believe right now if you just drop a long file into the Kaivo/Samples folder it will import the whole thing.
Some other folks have reported that enabling "Force MPE" in Bitwig is needed to get my instruments working there. Does that work for you?
There's not much context in your comment so I'm going to assume that you are in the common situation of using a MIDI keyboard, and don't want every note to start a new attack.
You might find unison mode helpful. I believe that if unison mode is on, and notes are played overlapping one another, the envelope will not retrigger.
Yes, one wonders how or if they are going to do that! I have not yet tried this but I'm interested to find out if it's "commercial quality" in terms of efficiency, sound quality etc.
This seems to work. You can always reach me at support@madronalabs.com.
Thanks for the idea. My initial reaction is, this adds such a great amount of complexity and that's something I am trying to avoid. I wonder if there's a way to make multiple instances of the plugin work better together to achieve what you want.
I'm imagining how this could be done in a future modular environment (as always) with one KEY module and several sub-instances of the plugins. This has the advantage that you can mix Aalto, Kaivo, etc.
Currently in Aalto each voice has its own send to reverb, however they all share the same reverb.
That's odd, I'll look at it. If you are not using the example patches that ship with the software, can you please zip up your MIDI Programs folder and send it to me so I can reproduce?
email me at support@madronalabs.com with some kind of documentation of student status and I'll sort out a refund.
It's still in flux. I'd hate to tell you something and then end up having been wrong. I think we can safely say it will be less wide than it is high. (how many HP is a square anyway?)
There is a beta out, which you probably saw, you can find in another thread. This should fix the sequencer issue. If you need this fix you can use the beta temporarily. I still have some other issues related to tuning files to solve.
This particular beta period has been longer than usual getting to completion—thanks for your patience.
If you are interested in helping out with testing, you can use the beta and give me feedback. If you are more interested in getting music made, use a stable version (in this case, 1.3.2). This beta process has been longer than usual and hopefully will be wrapping up soon.
The Seattle Music Machine Salon is a new monthly discussion group, open to all and free of charge. Each month we’ll have a presentation and a guided discussion on some aspect of making music with computers and electronics. Topics will include the practical and the not so practical: new software and hardware tools, compositional strategies, academic and popular styles of electronic music, its history and future.
Our first event is Friday, March 4 from 7 to 9pm at Ada’s Technical Books in Capitol Hill. Ada’s offers a comfortable, inspirational atmosphere, and great food and coffee. They are at 425 15th Ave East. Please visit their site at http://www.seattletechnicalbooks.com/ for more info and directions.
Everyone is welcome! This includes all ages and skill levels. The aim is to create a diverse group that will expand viewpoints and spark new projects. The only requirements are an interest in the topic and the ability to engage in respectful discussion.
March 4 presentation:
Randy Jones of Madrona Labs will demonstrate his new software instrument Virta, a patchable, sound-controlled synthesizer and effects toolbox.
March 4 discussion topic:
Seattle electronic music resources. What are some important foundations of the local scene for you? What are some less visible resources that should be better known?
Yes, we do one most months. A couple of times this summer we cancelled because it seemed like everyone would be out of town. There's a website: http://seattlemusicmachines.org/ and a mailing list you can sign up to from the menu on it.
I've had many requests for this. It will happen.