Flatten Nested Rings

Support, Help & Resources
1

Hi,

I have a few occurrances of expressions like:

sample xyz, beat_stretch: 8, rpitch: (knit (ring 9, 9, 7, 7), 2, 4, 4).flatten.tick

in some of my tracks and noticed that in SP 3.2 ring and/or knit do no longer accept/know the pure Ruby expression flatten. A simple list does. See:

yes = [-2, -3, [8, 2]].flatten
puts yes

no = (ring -2, -3, (knit 8, 2)).flatten
puts no

Is there an alternative to work with nested expressions like my example an turn these into simple and ‘tickable’ rings?

2

you can do this with the second one:

test1=(ring -2, -3, (knit 8, 2)).to_a.flatten
puts test1
test2=(ring -2, -3, (knit 8, 2)).to_a.flatten.ring
puts test2

i.e. you convert it back to an array with to_a and then maybe back to a ring again.

1 Like
3

1000 thanks! Tried different ideas but this one has not occurred to me…

4

I’m not sure I understand what the actual issue is here… when I run your examples @Martin I get this:

yes = [-2, -3, [8, 2]].flatten
puts yes

results in:

 ├─ [-2, -3, 8, 2]

and:

no = (ring -2, -3, (knit 8, 2)).flatten
puts no

results in:

 ├─ (ring -2, -3, 8, 8)

which seems correct to me… what are you expecting?

5

Sorry, I don’t think I added flatten when I rewrote the underlying ring data structure in the latest commits on GitHub.

I’ll add that next week.

Please do let me know if anything else is missing or behaving weirdly with the latest code!

6

what does this code really do ? How do you reach this point of complex code :slight_smile: ? Just to know, i’m curious :wink:

7

Oh, was this in a very recent commit? haha. I haven’t updated for about a week. That might explain it :joy:

8

Hi,

@ethancrawford yes, I checked out yesterday and compiled because I wanted to test the memory leak fix.
@samaaron, oh great. I thought maybe flatten was no longer supported. Conveniantly it seems not to be (well, double negative is always tricky)… :slight_smile:

1 Like
9

Well, this is nothing fancy, just arguably making use of knit (see language reference) to shorten the expression:

(knit (ring 9, 9, 7, 7), 2, 4, 4).flatten.tick

=

(ring 9, 9, 7, 7, 9, 9, 7, 7, 4, 4, 4, 4).tick

In the context of the code It results in a succession of a pitched sample sound over 8 (or so) bars like a harmonic sequence of chords…

10

Something which also behaved different in previous releases:

live_loop :kick do
  at (ring 0, 0.75, 1, 2, 3) do
    sample :bd_ada
  end
  sleep 4
end

throughs an error:

Runtime Error: [buffer 2, line 3] - ArgumentError
Thread death +--> :live_loop_kick
times needs to be a list-like thing

(ring 0, 0.75, 1, 2, 3).to_a or, of course, [0, 0.75, 1, 2, 3] will be accepted.

11

I dont doubt you Martin, but I copied your:

live_loop :kick do
  at (ring 0, 0.75, 1, 2, 3) do
    sample :bd_ada
  end
  sleep 4
end

into my SP 3.2 (Win 10 x64) and
it works with no errors ?

Eli…

12

Could be the same thing I noticed @Eli, where Martin seems to be using a bleeding edge Sonic Pi dev version, and I was a week behind - so I don’t yet have the breaking changes that he has. Maybe the same in your case?

13

Agreed. my 3.2 is the original release. I tend to let things settle before upgrading to
anything ‘new and improved’. :slight_smile:

Eli…

14

Hi everybody,

Maybe it would be worth to create a new git branch for recent developments ? no ?

The official release for version 3.2 is https://github.com/samaaron/sonic-pi/tree/v3.2.0
The master branch is the latest version but of course different.
i don’t learn you anything :slight_smile:
So a new branch ?

15

Yes, @ethancrawford is right. The reason for me being so impatient …

16

Presumably Sam will bump the version to 3.3dev at some stage. However, with there still being problems with the install working on some Windows machines he may be looking at a 3.2.1 first. Recent commits are to do with the build process and sorting memory leaks, ( which have been very useful) and I for one incorporate them in my Raspbian build.

17

If you want to build your own version you should either stick with the tags which are the actual releases versions and are therefore much more likely to be stable. If you use the head from GitHub then all bets are off and it may or may not work.

Therefore typically stick to tags unless you’re happy to accept (and hopefully report) issues.

1 Like
18

Hi @Martin,

please take a look at the latest commits on Github and see if they fix things for you :slight_smile:

19

Hi @Sam, thanks a lot! Not sure when I have time to compile but definitely some time this week. I will report back.

20

Shouldn’t be any need to compile anything - just update the ruby source and it should just work :slight_smile:

1 Like