#61

Yep, checked and overdrive is on by default in my standalone installation of Max 8. Let me know if there’s anything else I can test to work out what’s causing it.

#62

If you can make a little video or something I can point to, I can add it to the github issues page.

#63

Hi, @Rodrigo. First of all, as I’m sure you’ve been told before, you and raja have designed a truly awesome tool. So thank you for that.

Now, I need some help figuring out what in tarnation I’m doing wrong in a patch I’m currently putting together. I’m very, very new to patching in Max, so please excuse any and all ignorance.

In my mind, I’m trying to do something very simple: a patch consisting of four karma~s to create a quadraphonic four-track looper. I’m doing this by copying the kitchen_sink example into four separate subpatches where I’ve replaced the audio looper and ezdac with an inlet and outlet—pretty basic.

Now, I would think that if I changed the buffer name in the buffer~ and karma~ objects, along with the names for all sends and receives, that I would get four working iterations of the kitchen_sink setup. And to a degree, that is what happens. However, it’s only the original, non-renamed patch that seems to work fully.

The main problem with the subsequent patches (those where I’ve changed buffer/send/receive names) is that the waveform UI goes all funky. For the most part, all of the audio functions as it should. I just don’t get the graphical feedback that is so helpful.

What tends to happen is the waveform that fills the UI will either a) not show up at all, leaving a blank black UI; b) not appear while recording but then show up when I send a play message, but when it does show up, it doesn’t populate the whole UI from beginning to end, instead showing a big blank space after the waveform, as if amend is on, though it still plays the audio as if it is filling up the whole UI—in other words, it’s playing back audio but not lined up with what the visual waveform would indicate.

I’m trying to figure out what I’m doing wrong here. To reiterate: The only change I’m making to the patch is to remain 1) the karma~ and buffer~ objects; 2) the receives going into the karma~ object and in the p posWin; and 3) the sends for position/window, autoJump, overdub, and append.

Is there something I’m missing?

Thanks for any and all help you can offer.

(I realize that might be a bit confusing in written word, and it would likely help if I would post that patch. I’m away from my computer with the saved patch currently, but I can share it later this evening.)

1 Like
#64

Howdie.

So from what you’re describing I suspect you might not be renaming the underlying waveform~ objects from the help patch. They are kind of buried beneath a few layers of stuff, so you can check out this video here (specifically starting from around 4:08):

When making the original help files I didn’t anticipate what a pain that would be since most people would likely just copy/paste straight out of the help file.

The good news is that for karma 2.0 (which has been in the works) this will be handled much more elegantly.

But for now, have a look at that and see if that’s what the problem was.

2 Likes
#65

Oh! Very nice! I’ll give it a try when I get home tonight and let you know how it goes.

Thanks a ton for your help!

1 Like
#66

Took me a minute to get back to my computer for this, but it worked! Thanks a ton!

1 Like
#67

@Rodrigo

Maybe you can help with this. Karma is absolutely wonderful, but I’m having a wee bit of trouble with a patch I’m building.

image
image.png2398×1480 525 KB

I’ve add the capability to randomize buffer position and window size. It works great on the left looper. However, while the window size and position are being randomized on the right looper, the playhead still moves linearly through the buffer and doesn’t track with the randomized position. Any clue why that might be? Everything else is working fine.

Nothing fancy in the randomPos sub. Just a metro, some random, and some scaling.

#68

You did good by renaming the send to s k.position2, but you still need to keep the message boxes above it the same (position $1 & window $1). Those messages are key words to karma and can’t be changed that way.

The rest, from what I can see, looks fine.

1 Like
#69

And that was it! Hah, quite the simple fix!

1 Like
#70

Thank you so much @Rodrigo for sharing this external. It’s amazing and makes it so easy to make overdubbing loopers in Max/MSP.
I’ve read somewhere in the topic that a Pure Data port was considered. Has it happened ?

1 Like
#71

Not that I know of. I don’t know how complex the task would be, but the code is all on github (along with a 1.5 version, which is a stop gap to the complete rewrite that is 2.0).

1 Like
#72

Thanks. I have no idea how to make pd externals. Maybe @someone does ?
Is there a compiled karma~ 1.5 somewhere available ? What kind of improvements does it have compared to 1.0 ?
What can we expect from 2.0 ? Do you need testers ?
One thing I noticed on 1.0 is that engaging overdub produces a small “soft click”, even with zero signal going in. It’s not dramatic, but can be annoying when doing several passes.

1 Like
#73

There’s a compiled version of 1.5 earlier in the thread. It’s not super documented, though I think I included my test patch in the zip which shows a lot of the new messages it takes.

There’s a bunch of bug fixes and code refactoring but the main new/different things in it are the ability to have a @signal out for position, so you could use it as you might use groove~. And it also takes a variety of setloop messages, so you can programmatically define loop start/end points, which you could only previously do by manually record-ing and play-ing a loop.

2.0 will be a complete rewrite and overhaul (to make maintenance and future updates easier). There will be loads of core improvements, like removing clicks like you’ve mentioned, as well as hopefully having some time-stretching capabilities. There will eventually be separate objects too (karmarecord~, karmaplay~ etc…), to make it easier to use in contexts where syncing is important, and/or if people like the transport but not the playback etc…

4 Likes
#74

Looking forward to this, thanks for your hard work :slight_smile:

1 Like
#75

Nice !
The signal out for the playing phase is indeed very welcome. Would you advice “upgrading” to 1.5 if it was just for the signal output and the recording status, or might there be some new bugs ?

#76

Not all bugs are fixed, and there may very well be new ones that I’ve not found, but I’ve used v1.5 exclusively for the last couple of years with no issues.

1 Like
#77

That should do it, then. Thanks again.

#78

heyo, has anyone compiled v1.5 for windows? I could really use that new setloop functionality for a project I’m working on! thanks in advance!

edit: @bhUnLTD I saw in github you had it working in windows, any chance you can share?

or @Taubaland perhaps you could work your magic for me again? :innocent:

#79

I just built this from 1.5, let me know if it works!

karma~.mxe64 (95.5 KB)

2 Likes
#80

It works a treat, thank you so much! was starting to lose my mind wading through Max SDK and Visual Studio documentation that is way beyond my skill level.