New version of Punch-In Loops

[bsork]

I've uploaded a new version of the Punch-In Loops demo workspace. Parts of the original way of handling things have been changed, so now it's easier to add new "instances" (...a sampler, a midi piano roll, a XY control...) up to a theoretical total of 512.

I've also added various bits and pieces to "semi-automate" (is that a word?) the process. Some of that may be of use even if you're not the least interested in recording audio/midi/data loops on the fly.

I've even created a User's Manual!

As always: comments, bug reports, ideas are welcome!

[senso]

yes yes I try it.

[senso]

I'm very impressed by your workspace. I think it's the most complex I've never seen.
Also the documentation is very helpful.

Now it's my turn to make suggestions! (you can't imagine how I'm happy to do that...)

In this wkp, they are many great & good sounding elements but they are hard to integrate into an existing setup. We are almost obliged to use all your wkp.
Could you imagine to create a kind of simplified version with each elements in a simple patch that we could activate or route in the grid?

[bsork]

Hi!

I thought I had made it relatively simple to change things, but you're right; things are a bit tangled up with each other. I'm not sure if I understand what you mean by "element". Is it what I call an "instance"? If so, splitting them wouldn't be very hard, but I wouldn't mind getting a "wishlist" here on the forum on what to do.

BTW - do you think a "lite" version could be of interest for the distributions? Max four tracks, so that it can be used in the free versions, and stripped of some functions so that it's easier to understand and uses less CPU.

[senso]

I'm not very clear.
I mean by "elements" parts of wkp. I should say "instruments".
for example 'punch-in grain sampler', 'punch-in delay', 'punch-in sampler'.

Turn them into a single patch autonomous that I could add to my existing wkp very easily.

Actually if I want to use them I'm almost obliged to load the entire wkp.
Sometime I feel more comfortable with many small patches that I load, route & activate in the grid, instead of a couple of huge ones.

what do you think?

[bsork]

Ok - if I understand you correctly, I should add some "clean" patches with only the parts necessary to use a sampler or whatever without a lot of extras, or maybe different versions with more or less extras? In that case, I think the best way would be to keep the workspace as it is, but add extra "building-block" patches in the ZIP-file.

For example:
- A master patch without the grain beat part - maybe also a version without the speed and sync off rec options.
- Some (even simpler) variations of the Simple Sampler patch, and corresponding patches for grain sampler and MIDI.
- A couple of "record modulation" examples, but you'd have to add the modulation destination yourself.

The way I've constructed this thing, one has to do a little editing in the master patch and in the instances to make it work when changing/adding instances, but maybe I could use a more "generic" approach like setting the instance = track or something.

[senso]

The simplest way for users (me in particular!), should to group the master patch with each slaves.
For example, I need a 'grain punch-in loop', so I only take a single patch that contains all. (the rec button in on the patch it self, not on the master)

Actually, I have to load & activate two patches (master/slave).
what do you think?

[bsork]

Now I understand - and that shouldn't be very hard to implement either; a handful of "single instance patches".

I haven't thought along those lines at all, since one of the big points for me has been to have a "centralized" control of several instances, and be able to do the most basic operations using only a footswitch and perhaps a pedal. That can easily be accomplished in other ways in Usine - I know - but that's the way I've been thinking.

Your way of doing it is more in line with most other patches, and I'm pretty sure I could use some single instance patches myself.

Here's what I'll do: instead of the examples I mentioned, I'll create new scripts and patches with one sampler, one midi etc and add those to the zip-file outside of the workspace. I'll remove the less obvious functions like default presets and fade-ins after recording from these, and I'll add a new section to the manual. By having both the master/slave and single patch options, both ways of working would be accounted for.

OK?

[senso]

cool perfect!

[bsork]

Hi again - I've changed my mind (again!).

Instead of using "slimmed" scripts, I think I'll create similar standalone patches with standard modules. At the same I think it will be possible to take into account both tempo changes (but not time signature changes) and saving.

Right now I'm working on a patch with one sampler - but I still have some work to do. I'll put it in the add-ons when (if?) I have something that works. I thought that maybe instead of adding these to the existing Punch In Loops, it would be better to create a separate add-on with these patches lumped together when I'm finished.

What do you think?

[senso]

yes create a punch-in loop pack which contains a collection of small and independent patches.

Good idea.

[nay-seven]

this new version is really usefull !
bravo bsork
can't wait to have a look on the patchs collection

[bsork]

Glad you liked it nay-seven.

I'm still working on the first standalone patch with a sampler. Once that is finished, the next ones will be a piece of cake (I hope). As I've mentioned, I'm doing the standalone versions with standard modules instead of a script. This is partially to save some CPU when only an instance or two is needed, and partially just to see if I can...

Although the functions available will be somewhat different in the two versions, I'll try to create the patches so that it shouldn't be too hard to change an instance from being standalone to be controlled by the master patch, or vice versa.

[Vincent]

... and partially just to see if I can...

Ha-ha-ha!
Today is a funny day!
Hey Bjørn, you should have wrote: "just to see how I can". No doubt you can, crazy man!

[bsork]

Well Vincent, I've just started to realize that some of the things I've made quite easily with a script will need a lot of modules to function, and use quite a bit of CPU.

Most of the basics work in the version I've been fiddling with, but I think I'll throw in the towel and go for a single instance script anyway. One of the advantages of using scripts in certain situations, is that you can choose what calculations to perform. In this case, I need some bits to work while recording, others while playing, etc. When using modules, all the calculations are done all the time - unless I've misunderstood something.

[bsork]

I haven't been doing much with this the last few days, but I decided to give the module version a go again, and now it works. I found that I could drop some of the calculations; no need to have separate counters for bars recorded and bars played, for instance.

I think I have the first standalone version ready for upload tonight. As I've said earlier, some functions in the master patch version won't be available, but I have added something else instead.