Error on passing 'launch' to 'run'

[tsvetelin]

Hello! Snap! team!

I'm working on a music microworld where notes are blocks , tunes are scripts and few other blocks help composers-begginers to transform tunes .

I'm having some issues with the functionality that deals with blocks' metadata ( and ) when used with blocks that depend on . Here is a sample project with the issue isolated: Snap! Build Your Own Blocks

As you can see:

• both and work fine
• while
  
  and
  
  result with errors when the launch block uses in its definition:
  

I need this functionality to make this work: where chord transforms what's inside to a list of notes and plays them in parallel:

Am I doing something wrong? Maybe I can use cloning for parallelization, but It seems too much for that...

Thank you and good luck in Barcelona.

[joecooldoo]

Huh. For me, it instantly crashes the entire webpage.

[dardoro]

For the current version of , macro should be "run" in the context of the caller.
XI. Metaprogramming > [C] Macro @ Snap Reference Manual

[qw23]

@joecooldoo

it instantly crashes the entire webpage.

Same here, with: .

The other script: , reports:
"Type error. Cannot read properties of null (reading 'receiver')".

If you replace the inner with , everything works fine.

@dardoro

For the current version of , macro should be "run" in the context of the caller.

That does work, however it's difficult to see why, since: .

Update: I realize now that is not the primitive (I wonder why?).
Even so: why would that matter?

By the way

@tsvetelin

other blocks help composers-begginers to transform tunes

That's an interesting approach, I think complementary to TuneScope!

[bh]

Hi, welcome to the forum!

Have you looked at the TuneScope extension for music? You could see how they implement things like this.

Just curious, is there an official way to represent semitones in do-re-mi notation? DO# or something?

I don't have an immediate solution for you; we'll have to look into this.

[tsvetelin]

@bh

Have you looked at the TuneScope extension for music? You could see how they implement things like this.

TuneScope is great and one can do amazing things with it. For some reason the operations over the list of notes are not included in this version...

I like the idea of having a note/tune as a thing (script) that you can click on and listen to it, and then you can put the same object (script) inside another block to manipulate it and hear the result immediatelly. This way you don't have to talk about lists when introducing it. I blieve at some point I'll put the mechanism inside TuneScope. This is a link to the work in progress: Snap! Build Your Own Blocks

DO# is a valid notation. Just like you can play BACH, you can play MI-LA SI MI DO-RE which in Bulgarian means You are dear to me, Dore.

breaks the app as well:

[tsvetelin]

This works fine. Thank you!

Not sure why the other one doesn't work and what's the differense with this one. As far as I get it, with the of reporter we get the launch block in the context of the Sprite, which apperantly is not really the case in the example that crashes.

[dardoro]

Snap Reference Manual v8 ...

This macro capability isn’t fully implemented. First, we shouldn’t have to use the calling script as an explicit input to the macro. In a later release, this will be fixed; when defining a block you’ll be able to say that it’s a macro, and it will automatically get its caller’s context as an invisible input

So the example can be modified

The result of split >> join is not always directly runnable as explained above (and results are slightly inconsistent)

[qw23]

@dardoro

This macro capability isn’t fully implemented

I tried the provisional working version of Snap! 9.0, but that doesn't fix it.

[jens]

did you try the new this caller reporter option?

[qw23]

No, I didn't. What's the recipe?

[jens]

whaddayamean? It gives you the current caller's environment so you don't have to use the calling script to pass it into the macro. Isn't that what you were asking for?

[bh]

[qw23]

OK, that does work.
Now what’s the difference, in this case, between the new:

… and @dardoro’s suggestion of:

?
(I’m not being polemic, just trying to understand how it’s all supposed to work)

[dardoro]

@qw23

Now what’s the difference, in this case, between the new:

It's unrelated. Joined script needs SOME context. So

is equal to plain

"this caller" is a different context - crucial part of the macro concept.

[bh]

To my surprise, it makes no difference, even if you remove all the clutter of JOIN, SPLIT, and LAUNCH.

I swear there was a time when I understood THIS CALLER. (I'm the one who made Jens invent it!)

[tsvetelin]

If I got it right, joined scripts are macros, thus they need some context to run in. Right?

[tsvetelin]

@bh

Just curious, is there an official way to represent semitones in do-re-mi notation? DO# or something?

It rutns out that C# is Di and D flat is Ra.

Using sharps - Do, Di, Re, Ri, Mi, Fa, Fi, Sol, Si, La, Li, Ti, Do
Using flats - Do, Ra, Re, Me, Mi, Fa, Se, Sol, Le, La, Te, Ti, Do

Solfège

But here we say and write Do# or Re flat.

[dardoro]

@tsvetelin

If I got it right, joined scripts are macros, thus they need some context to run in. Right?

Yes

@dardoro

For the current version of , macro should be "run" in the context of the caller.
XI. Metaprogramming > [C] Macro, p.105 @ Snap Reference Manual

I think I should mute now, as Brian and Jens can give you a first-hand clarification.