mentioned earlier that while you can plug in a soundcard and do some linux manipulation to have it work, but it’s not an immediate use case that will work right away.
I’m experiencing ‘not-buying-norns’ remorse here. If anyone is experiencing ‘buying-Norns’ remorse and wants to swap, let me know
Played a pretty blissed/blistering session last night JUST controlling some modulars with SuperCollider as the driver. Honestly, a little excited now to think about the possibilities of norns for triggering / sequencing / control as opposed to synthesis, considering how much I was getting out of like 30 lines of SC code…
There’s been mention of Crow’s a few times – I haven’t seen anything though, did I miss a post somewhere?
polyphonic earthsea!!! (discourse only allows three exclamation points!!!)
Am I right in thinking that OSC and MIDI in/out are fed directly to/from the Lua layer, and thus avoid the pathway via SuperCollider? Or do they go via Sclang ⇋ Lua? I’m trying to think about if the whole MIDI control structures from SC are relevant to norns or no…
(Edit based on my improved understanding of MIDI in SC.)
yes. SC is the “dsp” which could (with effort) be swapped out for a different dsp application provided it adheres to the OSC protocol re: parameter reporting/etc.
the lua layer has all of its own MIDI, OSC, timers, and driver (libmonome, etc) interaction layers.
an easy way to remotely control ie pd would simply be to run it in the background, connected to jack, and pass OSC messages back and forth between lua and pd. so sc and pd would be running in parallel (note, i haven’t tried this.)
I see… Now, maiden has both Lua and Sclang command lines, so I’m assuming that Sclang is running, in essence, in parallel - either Lua or Sclang able to control the SC server DSP back end. In any case, this would mean that the MIDI processing and Pattern processing parts of Sclang are not integrated with the Lua side.
Is it May 22nd yet? Is it?
No really, is it?
matron is the lua part (really the core).
maiden is the editor which talks via websockets to
matron talks to
crone via OSC.
crone is all sclang, we don’t talk directly to scsynth.
@tehn while youre in the room
I have some loose ideas for apps and questions about feasibility of implementing them within norns environment
should i start an app ideas thread or keep everything in here for now?
i’d like a space where some of us who arent proficient with code can explain (and refine) our intentions and perhaps get a nudge from the community in the right direction to create it ourselves…or find where it might already exist
also i’d like to stimulate more discussion about UI design (where i thought the instrument / control composition thread would go)
I think it would be rad to make something (monochromatic) inspired by Justints which would display on norns screen
Or another example…
In my layman’s head, it would be nice to have a script that let’s me plug in a keyboard and execute tidal commands on norns to control a synth engine or sample buffer. If that is not realistic it would be equally nice to use a connected laptop for similar control.
Based on the specs for norns, and this article, it should be relatively straightforward to allow communication between
crone and tidal (and/or
matron) via OSC. Does that sound correct?
If so, can I help get this started? or would the scope of the project require:
- someone more skilled
- someone with a proto unit
I think that getting headless TidalCycles running on an ARM chip is not particularly easy (minimally you’d need to build yourself, including a haskell/ghc) - I’ve seen a few inklings that it’s at least possible. I’m not a Tidal pro, but it’s unclear to me how useful a livecoding language like Tidal would be if you were running it headless on a device and triggering things externally? For most uses I could imagine, it would be significantly easier to just talk to sclang (or directly to scsynth).
If you can make a network connection to an scsynth instance running on norns, you can probably point a Tidal instance on a laptop at it, though I suspect this would work cross-purposes with the norns engine itself. The only real challenge there - once your synths reach a certain level of complexity, they can’t be sent via OSC and have to be sideloaded - but tidal has a fixed set of synths, so that wouldn’t be too disastrous.
Tidal plus Norns, be still my heart.
Yeah I agree
I figured since these all speak OSC that there might also be a way to allow for additional interaction. I could be be completely wrong
If there’s anything I learned from using the grid with Max applications it’s that the grid lacks affordances. We need more rules about what patterns on the grid mean what and how to represent particular ideas. A design guide could be in order someday.
I would love this as well. I know my mind is going wild with ideas but I also have no clue about whether creating an asynchronous looper is a lot easier or harder than a reverb stompbox. Or how a drum backing track player with sequenced guitar effects for my metal band (I’m serious ) compares to a crazy granular sampler.
It’s already been said but, damn that Crow is a great looking piece! Fingers crossed someone can snap a little video of the Commend Norns appearances too.
i’m not sure what you mean by that
care to explain?
Ha, sorry, got into some experience design terminology there. I just have noticed some patterns are broken in the way grid applications work. Like some apps use low lighting to indicate a button can be pressed while others leave it blank and make you count how many squares to press. And sometimes it can be hard to tell what parts of the grid are meant to be interacted with and what parts are indicators or unused. That kind of stuff.
The UX of grid-based applications
UX of Music Instruments & Tools