Skip to main content


Here is something interesting.
Today I realised that #Orca can send MIDI CC signals, so really the possibilities are almost limitless, even in conjunction with #SunVox.
I know it's rather silly, but here's a sort of little #synthesizer powered by SunVox, but the whole interface is done in Orca. Of course I don't think it's all that practical, it's more of a concept. But we can automate things this way.
in reply to Devine Lu Linvega

@neauoire Yeah I used it, but turned out sunvox can do smooth changes between two values, so Z is not needed actually. If we are talking about same thing...
in reply to vacuumbeef

ah! okay, it's not needed then. It's only useful if you want to control the smoothing speed of the knob tweaking.
in reply to Devine Lu Linvega

@neauoire I had another question for you.
If I remember it right, it was a long time ago, I used to bang something like $bpm:130 in OrcaJS to obviously change the bpm. Looks like orca-c does not has $ at all, and in orca-uxn, although $ exists, there is no such function to change tempo. I'm right?
in reply to vacuumbeef

that was never standardized, I never found something that felt right. Somehow the command part of the port always felt a bit un-orca like, in the uxn version I removed it altogether, and just use it for includes.

It could be made to use its own rune, or maybe there's UX to change BMP that I haven't tried.

The reason $ is called self, was to manage all things related to the runtime itself. I could bring back commands to $ in orca-uxn if you're interested.
in reply to Devine Lu Linvega

@neauoire
It's not that needed and I too felt something unnatural in it, so I know what you mean.
I thought about it because of this auto-album idea - a lot of febrajam tracks have different speed. I guess I'll have to change bpm manually in right timing, which is not a problem, but for this reason, absolute album automation will not work.
And, unfortunately I won't be able to use the uxn version, with heavy sunvox projects it slows down a bit, so the tempo is unstable,due to my weak processor.
in reply to vacuumbeef

I've made a massive update yesterday that should make things 10x faster, but yes, I understand, for a full album it's going to be hard. Let me think on this today, maybe I'll find a solution.
in reply to Devine Lu Linvega

I have a livecoding gig coming up in a week, and I think I might also like to automate BPM.. now that you mention it-
in reply to Devine Lu Linvega

@neauoire You know, I am currently torn between wanting convenience and doubting that it can be made to fit the "orca way"
in reply to vacuumbeef

I might just go ahead and add $bpm:, anything else you might need while I'm at it?
in reply to Devine Lu Linvega

@neauoire Oh you know,
1) will be there any maximum value of bpm? (orca-toy has much slower maximum than orca-c, for example)
2) What do you think about reset? To reset the global clock to the first step in any moment.
in reply to vacuumbeef

I like reset, how about $time:0

In uxn orca, the bpm is a ratio of 1/60th of a second, so the fastest is 60 beats per seconds.
This entry was edited (1 year ago)
in reply to Devine Lu Linvega

@neauoire and by the way what do you think about making possible to go step by step back or forward? I mean from keyboard, like maybe < and >, I don't know. This is not to be done now, but in general. But maybe it can make things overcomplicated, I don't know, it's good to keep orca minimal. But on the other hand I feel like it should be there.
in reply to Devine Lu Linvega

backward is tricky, uxn doesn't have enough memory to keep copies of the previous frames in memory.
in reply to Devine Lu Linvega

@neauoire Maybe one frame would be cool though, I fucked up a lot of projects because I used to ctrl-z while keeping some area selected in orca-c, and in uxn orca it just writes z on the whole selection
in reply to vacuumbeef

I could keep 2-3 copies(depending how large the grid is), so 2-3 undo history.
in reply to Devine Lu Linvega

@neauoire If you represent changes to the grid somehow a frame can take up a lot less space. For example, I implement undo in a text editor using 3 kinds of records: insert char, delete char and move cursor. History is an array of such records. Makes the whole model of text editing reversible.

On the other hand the benefits might be lower in a CA with lots of animation like Orca. I think Game of Life wouldn't save much space recording just mutations.
in reply to Kartik Agaram

@akkartik the problem with orca is that time goes forward.

You might record a state X, but by the time you undo, the grid has changed a lot and the diff no longer applies.
in reply to Devine Lu Linvega

@neauoire Yeah, the animation I mentioned..

So when you say 2-3 frames, when you undo it would go back to the state when you made the change?

What if you put all changes to the grid on the history, whether they were automatic or not? Then on undo unwind all changes to last manual change.

You'd only have a limited history of n seconds. No edits in n seconds = 0 undo.
in reply to Devine Lu Linvega

@neauoire But actually going back is more important, than forward.
But if orca is about LIVEcoding, it does't fit into that concept I think, so forget about it.
in reply to vacuumbeef

Very cool :o

Orca question: how are you getting those values in -- comments? -- to feed into the output?
Unknown parent

vacuumbeef
@neauoire @akkartik what if you record exactly the presence and positions of objects, only that, not the whole evaluation state, and return without touching the 'clock', flying E's and etc.? What could be the problem here?

Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.