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
this should be easy to do. that is, use only the sclang+scsynth side of norns to act as the SC side of a tidalcycles session, host the haskell side on a laptop. make a norns engine that just starts
that said - i’ll admit that wasn’t immediately successful using the SuperDirt quark on norns. (it installs ok, but class isn’t recognized - weird.) other quarks i’ve tried are fine. so it will take some hopefully-small amount of fiddling.
not sure i can agree! sorry. in a nutshell i’d argue that affordance-based design is a poor fit for a minimal, hackable interface canvas, and your example of a “broken pattern” is really two equally viable patterns. but maybe on another thread.
this would be good to see. “composition” in that sense is technical and touches both on software design and interface design, but is more about the former - sorry about that.
but it would be interesting for me as a developer to see a collection of proposed specs on how to make best use of a minimal interface. of course idea of norns scripting is to also make the implementation itself maximally accessible, even for functionally dense interface specs.
The UX of grid-based applications
Part of my day job is documentation of UX patterns. I’ve found over the years that it works best to start with observation and documentation of things as they are, and as they are being used, before making proposals about improved patterns. New patterns should have multiple use cases before being introduced.
This attitude of learning from observation and use, and minimally interfering, keeps the standards process from becoming an impediment to design innovation.
An overconstrained and prescriptive design system can be a very brittle one. As soon as a designer feels their needs fall outside the system, the entire system is called into question. Often, documenting a system of design patterns becomes a koan in resilience through flexibility.
So, I’d recommend taking a long hard look at the grid’s greatest hits: earthsea, kria, meadowphysics, mlr, and see what you see in common between them. Start with documenting the patterns you see there, and see where it gets you.
Resist the temptation at first to recommend proposals for improvements, or lateral approaches that introduce entirely novel patterns. Wait until you can clearly articulate the material difference between old and new, with pros and cons and rationale for usage of this for that, and that for this.
And sometimes the answer will be both/and: more patterns than any one app is likely to use, because there is plenty of room for many apps in the world.
The UX of grid-based applications