Error on passing 'launch' to 'run'

Hello! Snap! team!

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

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

As you can see:

I need this functionality to make this work: image 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.

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

issue with launch script pic

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

Same here, with: issue with launch script pic.

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

If you replace the inner issue with launch script pic (3) with issue with launch script pic (4), everything works fine.

That does work, however it's difficult to see why, since: issue with launch script pic (2).

Update: I realize now that issue with launch script pic (5) is not the primitive issue with launch script pic (3) (I wonder why?).
Even so: why would that matter?

By the way

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

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.

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:

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.

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
issue with launch script pic (1)

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

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

did you try the new this caller reporter option?

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

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?

untitled script pic (3)

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)

It's unrelated. Joined script needs SOME context. So
issue with launch script pic (1)
is equal to plain
untitled script pic - 2023-07-13T014153.689

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

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!)

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

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

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


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