#749

ooooh… gonna need to look at the footprint for the new one.

Ordered a 2GB to test. 4GBs in north america are sold out or unavailable for a few weeks

1 Like
#750

Should be fine for Fates. The position of the mounting holes and the GPIO header have not changed. But in my case, the shape of the PCB does not match the position of the Ethernet anymore… Too bad :smiley:

And the block of USB has been moved slightly too https://static.raspberrypi.org/files/product-briefs/Raspberry-Pi-4-Product-Brief.pdf

07

1 Like
#751

Ah - I see… (you’re getting close to my situation of many multiple pcb revisions)

thanks for the product brief pdf link. :+1:

Does anyone have opinions on adding a heat sink to the Pi processor.

My 3B+ units run pretty darn hot most of the time.

#752

Where do you see any info on the CM4?

#753

Do you have a link to details on a CM4? My google-fu is lacking - can’t find much about it. I assume this is still a ways out in the future tho?

#754

As far as I can tell, the CM4 does not exist yet, and may take awhile to release due to the new chipset.

As to your heatsink question, I run my Pi 3B with a heatsink and it seems to help a bit, and a friend has a 3B with a heatsink and fan that he’s able to stably overclock.

#755

There is zero info on a CM4. But reading the schematic and specs of the Pi4B helps already to assume how a CM4 could look like / what will be possible. As the composer release is still at least some month away. For me it’s mostly about choosing the right path from here.
Building up on the CM3+ now might limit us from the start. At least in terms of USB IO. What i am really curious about is if they finally fixed the clocks for I2S. All Pi’s until now had issues with that > one reason that the norns has a fixed crystal oscillator for the CS4270 codec.

4 Likes
#756

doesn’t make a ton of sense to me.

norns scripting layer is a couple of things: 1) wrapper around hardware, 2) launcher / UI for user-created musical logic. those are singleton components by their nature. executing parallel musical logics (multiple lua VMs or something) poses challenges that are not directly related to compute resource allocation and are more about a) UX, b) managing parallel processes.

in other words: norns “scripts” are lua applications that can nest any number of abstraction; norns “engines” are SC classes or standalone DSP programs that can likewise nest any level of modularity.

you see norns “library” offerings just doing one thing. but IMHO that’s the nature of things that are shared. if i mash together several functionalities in one engine (which is super easy to do if you have some SC fluency) it’s not gonna be necessarily useful to a wide range of people with different creative needs. (e.g. i made an engine to play the set for the tour i’m currently on. it does three arbitrary things. it’s not a “tool,” it’s a piece. i do software architecture for my day job, not for my musical practice.)

the audio processing “guts” mostly provide SuperCollider classes for wrapping user code and talking to scripting layer. SC is already a rich development environment. i dunno what you mean by “multitracked.” if it’s polyphony/polytimbrality, that’s there if you want it already. if you mean more audio I/O, that’s a hardware limitation that is unrelated to cpu/ram/&c.

there is also a built-in effect chain in norns, that runs on a separate processing thread from SC and doesn’t directly compete for CPU resources. this stuff is hardcoded, but it can be extended to something like an LV2 host chain any time anyone wants to implement that. (i’ll help, but i can’t take it on.)

anyways, more processing power would allow you to do more in each of those environments. that’s awesome. the R engine is the norns modular and more CPU would let you instance more modules; nice. but i don’t see a qualitative difference, and there are plenty of optimizations remaining w/r/t how those environments make use of existing resources in CM3(+).

7 Likes
#757

I had no idea one could make personal scripts that were that powerful - I only recently started looking into Norns, and primarily as something to run on my Pi and control with my Push 2 (although I may someday DIY a grid). So it wouldn’t necessarily make sense to make a multi-Norns now that I’ve seen your explanation of how Norns works, but it seems the Pi 4 would definitely make it possible to make patches with more multitimbrality & polyphony and more complex FX chains using the existing scripting, which sounds awesome.

#758

the CM3+ had to have the CPU clock speed restricted compared to the rPI3b+ due to power supply limitations - not sure what they will do with the CM4, given the rPI4 requires another 500mA again. but given the rPI4 is a kind of ‘next step’ for rPI - I’d think they will try to address this on the CM4.

I know for Orac, there’s still room for improvement on the rPI3 since PD is not using multi-core, which i want to change - but that said, the extra memory, and improved performance on a single core will make a big difference even on the existing code base!

4 Likes
#759

I would hope that they wouldn’t break pinout/compatibility with the CM series as that seems like to be the whole point with those.

That being said, I’m curious what a CM4 would bring to the table.

The double (mini) HDMI is kind of weird (on the regular rPI4), but I guess there’s some super common use case that makes that worthwhile at a $35 price point…

#760

would one need to make a new kernel if updating to the Rpi4? or could you just swap your SD into the new Pi?

#761

I think they’re pushing the new version as a desktop replacement - site touts “we’ve built a complete desktop experience” - dual monitors is something lotsa people might want from a desktop.

I’m curious about this as well, but haven’t had time to dig around on github to find out more. I assume old kernel might just work, but there’s probably some new chipset stuff? I’ll report back when mine comes in next week.

5 Likes
#762

Dual hdmi for homebrew vr?

3 Likes
#763

I could see tons of it-support offices and manufacturing shops using these to run dashboards and server status etc.

2 Likes
#764

Hey. I’m going to be doing a bit of building and testing of a potential Norns layout tomorrow. I have 2 questions:

  1. I see some comments or mentions of transistors being involved in the button layouts to the pins. If there is a need for transistors, does anybody have a quick description about what I should do there to prevent an issue?

  2. I have found this fantastic looking audio card to use with the Pi. It has some good specs, including electrical isolation between the sound card and the I/O’s. It is driven by cs4265 codec. It’s specs can be found here:

https://shop.audioinjector.net/detail/Sound_Cards/Ultra+2

Any thoughts?

Thanks all!

#765

I have a couple of AudioInjector Ultra kits - yet to build them so can’t comment on how well they work. I did have some discussion with the developer during the kickstarter campaign and pointed him to monome / norns and modular in general as a target demographic for the board, and he certainly seemed to know his stuff, so hopefully that plays out well in the actual design.

I have no solid plan for when I’ll be completing the build of my kits - sometime in the next month or two - but I will report back on this thread.

1 Like
#766

@okyeron in your documentation for building a Norns on Pi, you mention for both screen types (ssh1106, ssd1132) when testing to change the GPIO pin in this line of code, if they’re plugged in to different pins.

This line in the code:

gpios=reset:15,dc:14

Say I want to keep the code the same, which pin, on both screen types, gets plugged in to pin 14 and which is pin 15?

#767

The pin choice there is arbitrary. You can choose whatever free GPIO on the pi you want to use. Then you define those when you use modprobe or setup an overlay.

DC and RESET are pins on the display, you can wire those to (most) any open GPIO on the pi.

for example I’m currently using DC = GPIO17 and RESET= GPIO4

then I’d use sudo modprobe fbtft_device custom name=fb_ssd1322 width=128 height=64 speed=16000000 gpios=reset:4,dc:17

in what you copied above, it’s using reset=15 and dc=14

(I changed from 14/15 because those area also the TX/RX pins for the UART and I wanted to be able to use the UART)

#768

Ah, on my ssh1106 the pins aren’t defined that way. I have one of the legit NewHaven screens showing up tomorrow that will most likely do better.

This is what the pins on the ssh were defined as, which led to my confusion:

image
CD2445B6-0A88-4154-B0F9-8B6F68F2EDCC.jpeg1125×1415 821 KB

But I had decided I’d rather just have the proper screen when I found some good sellers. I’ll use these ssh for a Pure Data synth instead.

Thanks for the reply. I’m going to follow the instructions again tomorrow. Fingers crossed.