#41

Yes, I have restarted Max.

#42

Here’s one with the package-info.json file made through Max. The first attempt was just me cobbling one together based on other examples.

karma_package_take2.zip (504.9 KB)

#43

I shut down Max, removed the old folder and put this new version in Max 7/Packages/, then restarted Max.

Same behavior. :frowning:

#44

Balls. I’ve submitted it to c74, so will see if they do something else to it and/or put it in the repo.

1 Like
#45

Hey folks,

could anyone explain how I install this?
Should I throw the whole karma folder in user/documents/Max 7/Library ?
and then? open karma~(b)/karma~.mxo?

sorry. I super rookie.

Thank you
KZA

#46

Yeah you can put it there, as long as it’s in the search path you’re good to go.

As far as using it, you can open karma~.maxhelp, or once you have it in your search path just make a new [karma~] object and alt-click it to open the help file.

You have to restart Max once you put it in the search path before it shows up

#47

Thanks a lot @Rodrigo

#48

karma question:

the first time i hit “record” it automatically disengages after filling the buffer. hitting record again, it will remain engaged indefinitely. is there a way to engage recording indefinitely from the get go?

#49

Aaah, as in automatically starting up in an ‘infinite loop’ type thing?

The easiest way to do that would be to create a buffer bigger than you plan on actually using and then start recording by sending record, then before reaching the end of the loop (as in, don’t let it time out) just send record again. That will go into overdub mode automatically and stay there indefinitely.

1 Like
#50

gotcha. thanks for the help.

#51

Hi @Rodrigo, I’ve been playing around with karma~ today and I’ve landed on what appears to be a very odd bug…

The right-hand data outlet seems to be working backwards for me, i.e. it doesn’t send out any info on play position, window size etc when the object is set to play or record, but it does send out a constant stream of data when the object is stopped. Which is obviously the reverse of what should be happening

The version of the object in the position / window tab of the help file does seem to work properly, but it takes several seconds for the waveform window and playhead to appear.

Any idea what might be causing this, or how to fix it? I’m using Max 8, inside Max For Live in Live 10.

#52

fwiw, my karma~ M4L devices have other oddities in Max 8-powered Live 9. reinstalling Max 7 and pointing Live to use it was the only workaround I could find :confused:

#53

Live 10 (at least my version of it) will only work with Max 8, it seems.

#54

It sounds like you might have some kind of override/scheduler jamming up issues?

If you copy/paste from the helpfile directly into to M4L does it work ok?

The current/normal behavior is that it will spam out stuff out the list outlet all the time (even when stopped). It will just spam out position “0.0” over and over until it changes. (I use a change 0. in my patch after each unpacked element to avoid this.

All that being said, I didn’t test karma~ 1.0 too thoroughly in M4L as I wasn’t using it much at the time. Any funny business should be ironed out for 2.0 though (along with tons of bells and whistles).

2 Likes
#55

It’s not anything else in the patch, sadly: I’ve copied and pasted the example from the help file into a clean m4l device, and then tried creating the simplest possible version, with just a karma~ object, buffer, play / stop / record message boxes and a print. I get exactly the same behaviour in both cases: info is spammed from the right outlet constantly while the karma~ object is stopped, but I get nothing when it’s playing or recording.

It’s good to know that 2.0 should fix this… any idea when it might be available? If it’s still a while away, has the 1.5 version on GitHub been tested with Max 8? From what Dan’s said it seems like karma runs fine in max for live under Max 7, so I presume it’s the different version of Max rather than the m4l factor which is key here.

I’m going to try installing Live 9 and Max 7 alongside my current setup as a workaround in the meantime, but I’m running into weird problems re-authorising Live, so that might be out too…

#56

Weird.

The 1.5 works fine (as far as I can tell), and it’s what I use exclusively now. There’s a few bugs still, but nothing massive.

It will still be a bit before 2.0 as 1.5 is kind of a stop gap to a complete rewrite. But it will mean lots of new possibilities and stuff.

#57

Yep, it’s really odd. Even weirder given that the version in the help patcher seems to work properly under certain circumstances, but not anywhere else.

Is there any chance you could share a compiled version of 1.5? I’ve downloaded Xcode and the Max SDK in an attempt to build it from source myself, but I’m getting an error message in Xcode saying that the i386 architecture is deprecated. I’m not a developer (hence having to download Xcode in the first place) so this pushes things way outside my ability to comprehend or resolve.

2.0 sounds great though, looking forward to it.

#58

Here’s v1.5. Unless you have a specific need/issue, I wouldn’t recommend using this over the release version as there’s different bugs/issues/functionality.

(this isn’t directed at you @ehg, but rather people who may just come upon this thread)

I’ve also included a (super messy) patch that shows a bit of the new functionality. There’s an attribute for @sync out (for driving other playback objects), you can setloop stuff, to arbitrarily define a “loop” section of the buffer. (handy for resizing the loop you already recorded), and there’s an extra value coming out of the list outlet which shows the current state of karma~ (very handy!).

karma~ v1.5q.zip (81.7 KB)

1 Like
#59

Thanks so much for this. Just tried it out and… I get exactly the same problems. It works as intended if I open in Max 8 Runtime, but not if I open it within Max For Live. Clearly there’s something uniquely screwy going on as a result of using those two together. In case it’s of any use, I’ve noticed while trying to get 1.5 to work that I get the same results no matter which inlet I send the record / play / stop messages to.

What a drag… looks like I’m going to need to work out how to re-authorising my copy of Live 9, or come up with some other solution. Oh well!

#60

Have you tested it in native Max but with “scheduler in overdrive” turned on?

M4L forces that option, as well as 128/128 I/O size (if I remember right, or maybe 64/64).