#21

Thank you for this incredibly useful page. I noticed that the Compass script is missing. Is there any specific reason?

#22

No. It’s just that the list is not yet complete :sweat_smile:

I add missing apps from time to time and people also propose additions. I’d say we’re 80% there.

It takes time to search each app features, make a non-poetic description and find appropriate demos and documentation if any.

Also, please note that I make mistakes from time to time (e.g. concerning the features, I don’t necessarily download each app to test them).

As stated at the end of the page contributions are welcome to speed things up and validate apps already registered.

1 Like
#23

I perfectly understand. So please take it as a contribution to improve the page :slight_smile:

#24

FWIW - the hardware section for Fates case options should maybe be acrylic/DIY instead of no?

1 Like
#25

@Cloud, Compas added, among others.

Fixed. Also would appreciate a review concerning the audio path field. Does the fate have an isolated audio power section like the original norns?

1 Like
#26

I’m not sure I understand the intent of the audio path field.

The DAC chip on Fates is powered by a separate precision voltage regulator (does this mean it’s isolated?), whereas I believe the shield DAC is powered directly from the RasPi 3.3v pin.

(However… In practice, “noise” in the design isn’t so much about where the power is coming from, but how analog/digital grounds are placed in relation to the audio and other signals.)

The compatibility field is also a question for me. Fates is fully compatible with all norns scripts. The underlying norns software stack does have minor tweaks and I maintain a fork for those - as you note this is in part due to using a different kernel - but I’m not sure that’s an important distinction for that comparison chart. (updates to the fork are usually made within a day or two of monome releasing an norns update).

Last suggestion/tweak - Fates has not been open sourced.

#27

Thanks for your time.

Oh yeah, this edit comes from @tehn. No voluntary finger pointing / name dropping, I guess he chose his words (“isolated” / “noise”) in a context of popularization, not scientific accuracy.

In practice that still makes an additional filtering stage for the powering of the audio section, right?

Does it really make a difference? I don’t know, depends on how well filtered the power coming from the RasPi GPIO pins is. Would need the user experience of somebody plugin in a crappy power outlet at a gig to really tell.
I guess it just means that it’s a more “following the textbooks” design. *

* I only have limited experience in analogue circuit design, not digital, and only as a hobby. So don’t hesitate to tell me if I say something utterly stupid or have any suggestion for a clarification that wouldn’t sound too nerdy for the average reader.

I agree this is misleading. Maybe should we rename this field to something else?

Something like update cycle?

And still keep a sentence bellow that states that all 3 versions are fully compatible with any app.

Oh I thought it was after stumbling upon https://github.com/okyeron/fates. I see the that the gerber are not on the repo. I’ll fix this sentence then.

1 Like
#28

I’ve been silently keeping this page up to date

Notable changes:

  • added a lingo section
  • used the scripts word instead of apps, as it seems to be more accepted by the community
  • almost 100% coverage of usable musical scripts
  • updated links to newer documentation
  • updated links/pricing according to newer norns shield offering (sturdier case)

I’m still very open to moving some parts of this page to the main doc (see my original comment).

Maybe people with experience authoring for the main doc (such as @dan_derks and @csboling) could help pinpoint what sections would benefit a merge?

10 Likes
#29

thank you for keeping this resource up to date :sparkles:

it’d be great to add some of the depth and specificity of the repo to this section of the docs: https://monome.org/docs/norns/app/.

these are the scripts that come preloaded on norns / are in the fresh image 
- arcologies (@tyleretters)
- ash (collected) 
- awake (@tehn)
- barcode (@infinitedigits)
- benjolis (@scazan)
- boingg (@Justmat)
- cheat_codes (@dan_derks) 
- compass (@Olivier) 
- cranes (@dan_derks 
- cyrene (@21echoes) 
- dronecaster (so many folks! initiated by @tyleretters) 
- dunes (@Olivier) 
- euclidigons (@synthetivv + @setfield ) 
- foulplay (@Justmat)
- glut (@artfwo) 
- greyhole (@Justmat) 
- less_concepts (@dan_derks) 
- lissadron (@LFSaw) 
- loom (@markeats + @instantjuggler)  
- mangl (@Justmat)
- mlr (@tehn) 
- molly_the_polly (@markeats) 
- moln (@jah) 
- oooooo (@infinitedigits)
- otis (@Justmat) 
- passersby (@markeats) 
- patchwork (@Olivier) 
- phyllis (@Justmat) 
- pools (@Justmat) 
- showers (@Justmat) 
- step (@jah) 
- timber (@markeats) 
- timeparty (@crim) 
- tuner (@markeats) 
- we (collected)
- wrms (@andrew) 
- why

starting points:

  • i like that the repo has granularity around script categories – that’s really helpful for orientation. on the docs page, it’d be great to find a balance so that no category has less than 4 scripts in it.
  • each of the stock scripts should be present on the docs page with a short description
  • i/o is a really crucial component, but i get absolutely lost remembering what each of the table columns indicate – maybe a legend can be established to indicate whether, for example, a script has baked-in crow functionality (eg. ^^) ?
    • it’d also be awesome to find a way to address questions about a script’s grid size (64 vs 128 vs 256) and brightness (varibright vs 4-step vs mono) compatibility

lmk your thoughts + if you have any q’s – thank you for offering your help! :rocket:

1 Like
#30

i might suggest the tag grid-legacy or similar to indicate specific support

1 Like
#31

I like the idea of tags very much.

We could even think of some basic filtering by tag with some minimal embedded JS.

Regarding the document format, I relied on tables while the official doc uses lists.

I guess, that we could keep using lists as they would offer to cram more content using multiple lines. E.g.:

  • awake default
    two looped sequences
    audio_out, midi_out, grid[128, *light]

My classification is solely based on the nature of the scripts while the current official doc one is mostly about their implementation (“softcut-based”, “synths and audio processing” for SuperCollider-based scripts).

I find my classification more user-friendly but the implementation detail (softcut and/or sc) could be nice to be kept as tags.

On the other hand, the official doc has a more fine-grained classification of sequencers that could be nice to keep.

Ideally, all mature scripts should be listed and described I guess.

Default could be marked as such with a tag.

Yes, tags under each script name could be a better way to represent those. We could even go crazy and use icons (like in @tyleretters dev skill map.

Different icons / tags could be used to mark support for various grid sizes / brightness capabilities.

1 Like