I think perhaps we’re talking at cross purposes. I am more than willing to add an “arm” button to the existing looper. I was just trying to determine exactly how you wanted it to work. It illustrates the difficulty of effective communication when discussing something from two somewhat different points of view. Perhaps I should just create something and see if it meets your needs. My intent in mentioning my original intent in creating the looper was really to explain why it lacks some features that you would expect in a practical device.
On a side note, I believe that you misunderstand the nature of the gates coming from my version of the master clock. I can’t speak for @biminiroad’s design, but in my case the gate does not last for the length of the period. The gate length is variable and is determined by the pulse width setting. At 50% the gate lasts for half of the period. For example at 50% the 2 bar output is high for one bar (4 beats) then low for one bar. If you set it to 25%, the 2 bar output would be high for 2 beats or 1/2 bar then low for 6 beats etc. The period of the gate is the time between two rising edges, so for a 2 bar gate it goes high every second bar. When used as a trigger the gate length typically doesn’t matter since it’s the rising edge that is the important event. If you’re using it as a gate to control something like a mute then clearly the length of the gate matters. By providing a pulse width control I hoped to provide some flexibility with the module.
I don’t know if you’ve had a chance to look at the transport collection I made a while back but you might find it useful for the kind of things you’re talking about. You’ve given me an idea for an additional module that would output a gate that goes high for a specified number of beats every time it receives a start signal. Since there are modules to generate a start every so many beats you would have a lot more flexibility.
Here’s a simple implementation of the arm switch. When the switch is off it blocks the incoming rec signal. When it’s on, it allows the signal to pass. In order for it to work the way I think you intend, you need to arm the rec when the incoming rec gate is low. Then it will start recording at the next high. If you arm the switch when the incoming gate is high, then recording will start immediately. Modified Arming simple looper.audulus (443.6 KB)
Here’s a demo of some of the the transport modules with the new gate module. It shows how the transport can create various gates and triggers as well as note clocks. The collection has flip-flops and switches as well for more complex routing. Transport gate demo.audulus (454.4 KB)
@stschoen you are a brilliant programmer! I went through your implementation of the PW gate clock that @futureaztec references in the patch above, and I spent a good hour going through and admiring all the pieces parts you built along the way to making this thing. It is a technical marvel, in its own right, and I just wanted to give you props on another well thought out utility! Well done, sir
P.s. The discussion of the module, and the subsequent build to spec you are willing to do for anyone who has a question, or a reasonable feature request, is a testament to the best thing about this forum. I love the sense of community and generosity, effectively sharing the wealth of knowledge that we all collectively play a role in shaping and contributing to, with our varied backgrounds and skill sets. This type of thing would never happen on the M4L forums without someone trying to capitalize off of the questions somehow. The Audulus forum is like no other community I have ever encountered, and I hope it never ceases to be the way that it is.
I think that there are 3 things exceptional about @stschoen’s presence here.
You hit one on the head. I am not a programmer but he still cares to discuss functionality with me. So I think that what makes Audulus special is that very difference of care. The thing is, that can’t be designed. It’s a personal ethos which makes the development here priceless.
Another thing is that he is interpreting white papers and dealing with differential equations, then integrating it into Audulus. You know, the reverb’s are pretty good, for example.
Finally, he makes novel modules based on inspirations from eurorack modules and other sources of interest. Some of these are better than the hardware versions and he could actually go into production on them.
Personally, ever since I combed through the library I have had a hard time getting interesting in digital hardware eurorack. One day it would be fun to have an actual board wired right to the software so that one could play with physical-logical relationships of analog components without being tied down to one arrangement. Like virtual bread boarding with physical caps, resistors, diodes, etc. Or, if the cpu for audulus could be an external unit. At the same time, the cpu limits do lead to cleaner algorithms.
@futureaztec Have you checked out the Empress Zoia Euroburo? I don’t know when it will be out, but it seems like it will be the most awesome thing to happen to Eurorack DSP ever. It’s like what you just described, with the Audulus type of capabilities, on a dedicated unit.
I was going to buy it when it came out in the next few months, as I felt it would be the best thing to handle overflow that my iPad Pro 10.5” couldn’t handle out in the world, away from my iMac. The problem is, I don’t yet know when it will be out, the cost is uncertain, getting hands on one is going to be difficult, and on top of all that, I would have to figure which of my modules would need to be axed to get the extra 18-20 hp that would be necessary to fit the 34 or 36 hp module in my rack.
I really like my setup the way it is, and so I opted to go with 2 Disting modules instead. They may not be quite as capable, but they will definitely take some of the load off of my iPad CPU and RAM. That is good enough, and if it turns out that the Euroburo is something I absolutely cannot live without in the future, I can get the external case they are offering for it to be a standalone desktop unit.
For now, I think I will be happier with what I have, but I think it might be something you would be interested in checking out, due to the mention of the virtual bread boarding and prototyping of modules on something more dedicated than a general use multimedia production/consumption tool. There definitely is something to be said for a unit that is purpose built, when you start running into the limitations of the hardware in iOS.
Audulus is the way. For example, I was just digging back through @RudigerMeyer’s work on Hordijk. He has made some interesting oscillators. I think the key is trying to understand what’s happening to some degree. Motivation is an elusive ingredient for some people. I want less gear, more deep understanding. As time goes on, if you don’t lose your way, this more subtle infinite joy can flourish. The gear can actually destroy it. This is why I am working on this thread, trying to help Audulus grow.
@futureaztec and @stevo3985 I think the thing I like most about our little musical community is the sense of shared purpose. We have a wide variety of ages, musical backgrounds, interests and skill sets but we are joined by a common interest in audio synthesis. When I first purchased Audulus, despite having been an amateur musician for many years, I had little practical knowledge of musical synthesis. I knew the basics but little more. During my time participating in the forum, I feel like I have received as much as I have given others. I now know far more about the details of synthesis and about the musical styles it contributed to. If I can help others in the same way that I’ve been helped, it only seems fair that I should do so. We all have our areas of expertise and it’s the synergy between us that often results in the most outstanding creations. It’s far too easy to get stuck in a particular mode of thought and often what seems the most appropriate choice for a design can be significantly improved with input from others. I am constantly surprised by the patches that others have created using the modules I’ve developed. That sense of “I never thought of doing that” is one of the joys of sharing. A different point of view often illuminates the strengths and weaknesses of your own. It also doesn’t hurt to have an audience for your work that is familiar with the tools we all work with. No one can better appreciate a piece of music than those who play the same instrument as it were. I value our friendship and our shared journey, and I’m sincerely glad to have met you and all the fine folks here.
For all that has been written i am really struggling with the relationship between the master clock 1.3 and the armed Simple
Looper
1234 1234 1234 start…huh?
I tried it against the original master clock for the reface library. That clock seems to be on point. So then I thought it might be the count in. I backed that off and it solved the issue. So it looks like the count in function is throwing things off. Is there a way to preserve that feature and maintain the bar counts?
I was wondering about that while I was playing with it this morning. If the count is off I’m sure it can be fixed. I’m also working on a better arm circuit for the looper. Still have a few details to sort out.
No wonder you’re having troublewith the clock. It’s not working on the iPad anything like it does on my Mac. Some sort of timing issue. I’ll sort it out
As far as I can understand, this work is fantastic even with Audulus 4 down the road. All of the beta testing will have been done for a whole suite of tools. Having an excellent set of clocks, mixers with sends and mutes, time syncing for delays, all of the fm work (the multi operator stuff, the drums, voices), various other oscillators, array of filters with drive and some multimode, @J031’s effects, your Turing variations, @robertsyrett’s Citrus Seq and reticulated gate seq, and on and on. Things seemed to have really tightened up, especially thinking of today vs. how things were happening on the old forum.
I think that if anyone runs out of ideas, just looking back at the old forum archive and refurbishing stuff would be good. There is so much still hidden in there.
The key idea behind the reface collection was to prepare for A4. The DSP engine is largely the same so most things should port without too many problems. Since @biminiroad is no longer with Audulus I don’t know what the new library will look like but the reface modules will be viable in any case. I’m a bit under the weather today so it’ll probably be tomorrow before I can work on the clock. I tried to graft the count-in onto the existing design and that turned out to be a poor decision. I never realized how broken it was on the iPad since I do all my building on the Mac. I was in bed today so I was using my iPad to test and finally saw the problem you are experiencing. I have a more integrated approach in mind that shouldn’t suffer from the feedback timing issues that are plaguing the current design.
Yes. No rush. In fact, I find that when I am working on something I need to relax with it like Archimedes. I was lost, but when I woke up I was at least able to diagnose that it was the count-in causing the bars not to line up.
Not sure how hard of a cpu hog pwm is, but it seems like a bit of a luxury, no? Also, if adding a reset output is really simple, that would be nice. Believe it or not, the reset output on-board the clock seems to be important for larger generative patches.
I hope you feel better and, again no rush I am busy with a million chores .
The pulse width control doesn’t really add much overhead. The problem with the current design is that I chose to generate a reset at the end of the count-in rather than simply wait until after the count-in to start the main outputs. On reflection the latter approach should be simpler and not subject to the timing issues that the former caused. Feedback circuits in Audulus are always tricky. Since nothing actually happens simultaneously in the digital realm the order in which parts of the patch are executed can be a problem at times. Unlike Max/MSP and PD, Audulus doesn’t have a predefined order. Even though this sometimes causes issues, I prefer it for simplicities sake. In Max and PD the spacial arrangement of nodes determines their order of execution, so moving something to another location can break a patch. More robust but less intuitive.
A reset is certainly possible. I assume you want a pulse when the clock is stopped. You’ll note that the reset signal is an important part of the transport collection I referred to earlier.
As far as the looper is concerned, I believe I have a more workable approach in development. It works as follows:
looper armed and first clock received starts recording. looper is then disarmed.
looper stops recording on next clock and switches to playback.
if looper is re-armed, it switches to overdub at the next loop start and the looper is disarmed
The only remaining decision is whether the looper should switch back to playback from overdub at the end of the loop or continue in overdub until re-armed. What do you think?
Just at work on break. The scenario sounds good so far but it’s tough to tell until you have a guitar in hand and start trying to produce layers. Things were very close before and I see some of the layering being done by 3 or 4 loopers. I think that once it gets to that point things are going to get really interesting.
I also think that having a mutable/gateable mixer with about 4 sends would be smart, but I don’t know what the cpu hit on that would be, nor do I know if mono lightens it by much.
For me, the purpose of the reset is to get all software and hardware to clear after about 64 bars. But you want the reset when clock is initially started as well.
A reset pulse at clock start could be a bit problematic. In order to guarantee that the reset takes place before the first clock pulse it would be necessary to delay the clock start until the end of the reset pulse. This means that the clock start would be delayed and would not actually begin when triggered which could result in timing issues.
I find the background detail you share very interesting.
Gearwise it’s nice to have the option that Audulus + ES-8 can provide a master start+reset; or, that say a Digitakt can be the master to Audulus. Giving or, accordingly, receiving a reset seems to be the main factor that separates a master from a slave.
I may be wrong but I thought the reset that could, imaginably, come out of this clock would be simultaneous to the clock start in this case — which would effectively make it a master clock. Seems like, at some point, the two should be differentiated first by this master/slaving of reset. I never really thought about it. Does that make sense?
Having another look, I see it is set up to take a reset.
Not only that, but after testing it I remember being very satisfied with how well it slaves. I would almost rename the syncable clock as a “Slave Clock.” I believe I was tempted to think of a “master clock” as being feature rich, when really, again, it seems mostly to have to do with the giving or receiving of a reset gate.
The key point is that in Audulus nothing happens simultaneously. Ultimately the code is executed one step at a time, so it isn’t possible to have the reset pulse occur exactly at clock start. One or the other will necessarily be first. If the clock start comes before the reset, then any circuit that has already processed the first clock will be reset leading to the kind of issue that caused the count-in problem. You can generate a reset before you start the clock but because the clock start is delayed from it’s trigger, it’s possible that you could introduce timing problems if you need the clock to start in sync with something else.
It’s usually better to generate the reset separately to ensure that everything is properly reset before the clock starts. By creating a reset at clock stop you can reset everything at the end so that it’s ready to start again.
Keeping the clock synced is a separate but related issue. The sync input on the phasor and oscillator nodes is also a type of reset which sets the output to to the beginning of its cycle when triggered. By periodically triggering this input you can force the oscillator to stay in sync with another.
Whether a unit is master or slave depends on it’s currrent role. Many devices can be either or both depending on their current role.
.