Hi,
This is really a question for any Apple Scripters out there.
Right now I am looking into adding AppleScript support to Scrivener for 1.1.
The programming side of this looks do-able, but my main problem is that I don't actually use AppleScript.
So, I would just like some feedback on what users think the essential features of a Scrivener Scripting Suite should be.
In other words, imagine opening up Script Editor and opening the Scrivener AppleScript dictionary. There you would find the Standard Suite and the Text Suite, with all of the regular classes and elements in them. But you would also find the Scrivener Suite.
My question is, what would you expect to see in the Scrivener Suite? What sort of things should be exposed. Scrivener is pretty big, so I cannot expose everything, but what are the sort of things that should be exposed for general scripting purposes?
Thanks for your feedback!
Keith
AppleScript: what do you want to see in the Scrivener Suite?
-
Lord Lightning
- Posts: 652
- Joined: Fri Jun 23, 2006 4:58 am
- Location: Somewhere else!
I still dream of using Scrivener for screenwriting - from start to finish. So being able to switch on a suite of screenwriting tools done in Applescript woud have a lot appeal. Come to think of it Apple script additions could also lighten the footprint of an ever growing application.
I have almost no need for the Markdown function so that would be nice as a script - switch on when needed (if needed).
If you think of the huge load of extras you have added since the Gold build to address people's needs, quite a few could have been accomplished in Applescript.
Please don't misread this - I love this app to death. I am happy with it as it is. I was happy with when it went Gold. I am amazed at how you keep spinning the magic into Scrivener. I just keep thinking how it might be if the core application was lean and mean and the 'fluffy bits' were add ons or scripts.
Fantastic idea - but Hey! I'm happy just as things are now.
I have almost no need for the Markdown function so that would be nice as a script - switch on when needed (if needed).
If you think of the huge load of extras you have added since the Gold build to address people's needs, quite a few could have been accomplished in Applescript.
Please don't misread this - I love this app to death. I am happy with it as it is. I was happy with when it went Gold. I am amazed at how you keep spinning the magic into Scrivener. I just keep thinking how it might be if the core application was lean and mean and the 'fluffy bits' were add ons or scripts.
Fantastic idea - but Hey! I'm happy just as things are now.
Lord Lightning
I'm a writer. I create worlds!
When I make a declarative statement it applies to ME. Not to everyone.
I'm a writer. I create worlds!
When I make a declarative statement it applies to ME. Not to everyone.
-
KB
- Site Admin
- Posts: 20716
- Joined: Tue Jun 13, 2006 11:23 pm
- Platform: Mac
- Location: Truro, Cornwall
- Contact:
Well, I certainly would not be cutting anything out. I'm not really sure how of this really could have been achieved in AppleScript - some, definitely.
Anyway, I welcome suggestions for what should go in the Scrivener Suite!
Best,
Keith
Anyway, I welcome suggestions for what should go in the Scrivener Suite!
Best,
Keith
Great news, now just a few ideas for the beginning:
- Importing a larger File and dividing automatically wherever a header is, (Cmd-K if done manually)
- Export draft with automatically setting the folders and documents to export to those actually open in Edit Scrivenings.
- Changing all annnotations to footnotes or certain highlights and vice versa
- Changing fonts
- backing up with comment dialog in order to add meta data to the archive
- exporting all snapshots and deleting them in Scrivener.
OK, I will stop here and wonder whether these should be AppleScript or implemented into the application. There may come up some processes today when writing which will remind me of Apple Script.
Thanks for considering AppleScript and best wishes,
Maria
- Importing a larger File and dividing automatically wherever a header is, (Cmd-K if done manually)
- Export draft with automatically setting the folders and documents to export to those actually open in Edit Scrivenings.
- Changing all annnotations to footnotes or certain highlights and vice versa
- Changing fonts
- backing up with comment dialog in order to add meta data to the archive
- exporting all snapshots and deleting them in Scrivener.
OK, I will stop here and wonder whether these should be AppleScript or implemented into the application. There may come up some processes today when writing which will remind me of Apple Script.
Thanks for considering AppleScript and best wishes,
Maria
-
KB
- Site Admin
- Posts: 20716
- Joined: Tue Jun 13, 2006 11:23 pm
- Platform: Mac
- Location: Truro, Cornwall
- Contact:
Hmm, these sound slightly odd requests for AppleScript... Most are more like wish list items! (Or things that could be added via AppleScript.)
Maybe I should clarify a little: I'm not asking for suggestions about what should be added via AppleScript - that is up to users who use AppleScript and want to share their scripts at a later date. Rather, I'm asking those already familiar with AppleScript to state what they would like to see exposed to AppleScript via Scrivener. For instance, you might have a script class called "project" which contains "mainDocument" and "supportingDocument", each of which contain "text". Uh, except Scrivener is a little more complicated than that. But basically I'm just asking AppleScripters what they want to see available in the Script Editor dictionary.
Thanks and all the best,
Keith
Maybe I should clarify a little: I'm not asking for suggestions about what should be added via AppleScript - that is up to users who use AppleScript and want to share their scripts at a later date. Rather, I'm asking those already familiar with AppleScript to state what they would like to see exposed to AppleScript via Scrivener. For instance, you might have a script class called "project" which contains "mainDocument" and "supportingDocument", each of which contain "text". Uh, except Scrivener is a little more complicated than that. But basically I'm just asking AppleScripters what they want to see available in the Script Editor dictionary.
Thanks and all the best,
Keith
-
AmberV
- Posts: 23616
- Joined: Sun Jun 18, 2006 4:30 am
- Platform: Mac + Linux
- Location: Ourense, Galiza
- Contact:
I have to admit, this is something that I haven't given a lot of thought, having had it in the back of my head that it would be a remote possibility in the distant future. At the same time, providing what is essentially an API to a complex application is pretty significant task. You want to strike a balance between abstraction and detail.
Take a look at OmniOutliner Pro's dictionary. That is a classy (though a bit exhaustive!) example of how AppleScript should be supported. Not everything is directly translateable, but there are some good ideas in it, I think. Afterall, this is the dictionary that allowed Ethan to take an ordinary outliner and turn it into an automated cross-referenced to-do list with iCal synchronisation.
Some obvious things would be full access to the Binder. Allow the creation, movement, and deletion of items within it. This would probably be most easily accomplished by allowing the scripter to assign item objects to variables, and a battery of methods which allow a full range of horizontal and vertical movement, adding, and trashing. This would probably be best done by providing the ability to assign binder objects to variables, and using them as targets in the move commands, basically what the Move To menu currently allows. I wonder if relative up/down/left/right movement would be handy for some people, too?
Addressing objects in the Binder is something that would need a little thought. Since items can have identical names, access to the underlying reference number would be important. Fixed items such as the Draft should probably be accessible by name.
Another area that could be addressed is aspects and settings of the project itself. You probably would not want to go too far into that--but I can see how the setting of some things would be nice to add. For example, the ability to hold label/status in an array. Editing them would probably be unnecessary, more important is allowing the script to "know" what meta-data exists in the document, for the purposes of assigning them to binder objects. Of course there is the project notes, references and scratchpad. The contents of these should definitely be accessible, perhaps not the functions of them. For example, there is little reason to script Scratch Pad's handy data movement feature, since a script can just as easily do that itself.
In the Document object. One would definitely want access to the two rich text areas: Main edit and Notes (see next paragraph for details). Synopsis, Title, and other meta-data. A good question would be how to address label/status, since each project can supply its own nomenclature. The simple answer would be simply to call them label/status, but that is merely the default nomenclature. Perhaps referring to them as their Corkboard appearance refers to them: pins and stamps? Keywords are pretty straight-forward. That is just an array. References are a little more interesting, but a reference object with a name and URL would be pretty easy to interface with, I think, but a better question would be whether or not there would be much third-party need to mess with reference lists. I suppose it could be handy if you have a list of URLs and wanted to turn them into references.
In the text itself; have a look at OmniOutliner's dictionary in the Extended Text Suite section; lots of useful methods in there. Footnote/annotation toggle on ranges, and the ability to linkTo binderItem, and unlink on a range of text. Scripted link manipulation could be very useful. Annotation and footnote access would be more important in the import/export type scripts. This could potentially expand Scrivener's ability to interface with odd applications. For example, getting Page's comments and annotating them correctly, or vice versa. Access to highlights would let a person go through the entire project, highlighting a certain phrase they know from experience they tend to abuse.
Splits would need to be addressed. There needs to be a keyword to operate on the focussed split, as well as the unfocussed split. The ability to test if the editor is currently split or not. Either that or 'smart' handling:Would just get text from the editor if no splits are open, as would from unselected split.
Maria, your suggestions are more along the lines of implementation than syntax and access: Here are some possible methods and their requirements.
This should be a fairly easy script to write if you have access to the rich text and rudimentary Binder manipulation. You wouldn't need access to the cut command per say, as you can find spots in a text string, split the string, and create a new document with string2. The ability to create a new document with a rich text block in place--would that bypass Scrivener's auto-Synopsis?
This would need the ability to grab the binder items currently represented in the E.S. session; and it would also require access to the focussed split, as well as the export settings (which may be overkill for round 1).
I'm not sure what you mean with this one. Do you mean the ability to create named snapshots? That is actually an interesting idea. You could create 'machine friendly' titles that saved the meta-data. It is prone to failure though, unless you are pretty careful about keeping labels/status around even after nothing current is using them. What is the length limitation on snapshot titles? Making snapshots in general is probably not a bad idea, actually. It would make running a script much safer if you knew it would back up the current text before slicing and dicing.
Anyway. I am not a super-experienced AppleScript coder. I know enough to create some simple automation or edit things that others have done. This will all benefit me in the end though, through the OSA. This all would put Scrivener out on (yet another) platform of its own. There are very few authoring programs with good AppleScript support.
At the same time, providing what is essentially an API to a complex application is pretty significant task. You want to strike a balance between abstraction and detail.
Take a look at OmniOutliner Pro's dictionary. That is a classy (though a bit exhaustive!) example of how AppleScript should be supported. Not everything is directly translateable, but there are some good ideas in it, I think. Afterall, this is the dictionary that allowed Ethan to take an ordinary outliner and turn it into an automated cross-referenced to-do list with iCal synchronisation.
Some obvious things would be full access to the Binder. Allow the creation, movement, and deletion of items within it. This would probably be most easily accomplished by allowing the scripter to assign item objects to variables, and a battery of methods which allow a full range of horizontal and vertical movement, adding, and trashing. This would probably be best done by providing the ability to assign binder objects to variables, and using them as targets in the move commands, basically what the Move To menu currently allows. I wonder if relative up/down/left/right movement would be handy for some people, too?
Addressing objects in the Binder is something that would need a little thought. Since items can have identical names, access to the underlying reference number would be important. Fixed items such as the Draft should probably be accessible by name.
Another area that could be addressed is aspects and settings of the project itself. You probably would not want to go too far into that--but I can see how the setting of some things would be nice to add. For example, the ability to hold label/status in an array. Editing them would probably be unnecessary, more important is allowing the script to "know" what meta-data exists in the document, for the purposes of assigning them to binder objects. Of course there is the project notes, references and scratchpad. The contents of these should definitely be accessible, perhaps not the functions of them. For example, there is little reason to script Scratch Pad's handy data movement feature, since a script can just as easily do that itself.
In the Document object. One would definitely want access to the two rich text areas: Main edit and Notes (see next paragraph for details). Synopsis, Title, and other meta-data. A good question would be how to address label/status, since each project can supply its own nomenclature. The simple answer would be simply to call them label/status, but that is merely the default nomenclature. Perhaps referring to them as their Corkboard appearance refers to them: pins and stamps? Keywords are pretty straight-forward. That is just an array. References are a little more interesting, but a reference object with a name and URL would be pretty easy to interface with, I think, but a better question would be whether or not there would be much third-party need to mess with reference lists. I suppose it could be handy if you have a list of URLs and wanted to turn them into references.
In the text itself; have a look at OmniOutliner's dictionary in the Extended Text Suite section; lots of useful methods in there. Footnote/annotation toggle on ranges, and the ability to linkTo binderItem, and unlink on a range of text. Scripted link manipulation could be very useful. Annotation and footnote access would be more important in the import/export type scripts. This could potentially expand Scrivener's ability to interface with odd applications. For example, getting Page's comments and annotating them correctly, or vice versa. Access to highlights would let a person go through the entire project, highlighting a certain phrase they know from experience they tend to abuse.
Splits would need to be addressed. There needs to be a keyword to operate on the focussed split, as well as the unfocussed split. The ability to test if the editor is currently split or not. Either that or 'smart' handling:
Code: Select all
set edit_me to rich text from selected split
Maria, your suggestions are more along the lines of implementation than syntax and access: Here are some possible methods and their requirements.
Maria wrote:- Importing a larger File and dividing automatically wherever a header is, (Cmd-K if done manually)
This should be a fairly easy script to write if you have access to the rich text and rudimentary Binder manipulation. You wouldn't need access to the cut command per say, as you can find spots in a text string, split the string, and create a new document with string2. The ability to create a new document with a rich text block in place--would that bypass Scrivener's auto-Synopsis?
- Export draft with automatically setting the folders and documents to export to those actually open in Edit Scrivenings.
This would need the ability to grab the binder items currently represented in the E.S. session; and it would also require access to the focussed split, as well as the export settings (which may be overkill for round 1).
- backing up with comment dialog in order to add meta data to the archive
I'm not sure what you mean with this one. Do you mean the ability to create named snapshots? That is actually an interesting idea. You could create 'machine friendly' titles that saved the meta-data. It is prone to failure though, unless you are pretty careful about keeping labels/status around even after nothing current is using them. What is the length limitation on snapshot titles? Making snapshots in general is probably not a bad idea, actually. It would make running a script much safer if you knew it would back up the current text before slicing and dicing.
Anyway. I am not a super-experienced AppleScript coder. I know enough to create some simple automation or edit things that others have done. This will all benefit me in the end though, through the OSA. This all would put Scrivener out on (yet another) platform of its own. There are very few authoring programs with good AppleScript support.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
KB wrote:...
Maybe I should clarify a little: I'm not asking for suggestions about what should be added via AppleScript - that is up to users who use AppleScript and want to share their scripts at a later date. Rather, I'm asking those already familiar with AppleScript to state what they would like to see exposed to AppleScript via Scrivener.
...
OK, I thought you would extract what has to be exposed via AppleScript from requests like this and dictionaries already present for other applications.
And as I stated, these processes could be part of the Application as well. I understand and use AppleScript as an extension of the application.
Maria
AmberV wrote:...
Maria, your suggestions are more along the lines of implementation than syntax and access: Here are some possible methods and their requirements.
...
AmberV,
you do what I thought Keith wanted to do: Collecting ideas of what could be done and then extracting the features AppleScript needs to expose.
AmberV wrote:- backing up with comment dialog in order to add meta data to the archive
I'm not sure what you mean with this one. Do you mean the ability to create named snapshots? That is actually an interesting idea. You could create 'machine friendly' titles that saved the meta-data. It is prone to failure though, unless you are pretty careful about keeping labels/status around even after nothing current is using them. What is the length limitation on snapshot titles? Making snapshots in general is probably not a bad idea, actually. It would make running a script much safer if you knew it would back up the current text before slicing and dicing.
I already like the titles of the zipped backups very much: Project name and date-time, very helpful. I thought of exposing an additional dialog (which could be done by Scrivener or AppleScript) to add a comment like "State before deleting reordering chapter 6 according to the ideas in ..." or "state before moving the project to the iBook". -- Of course, all this can be done with other means as well, but we were asked for AppleScript, and I thought of usage scenarios.
As for snapshot, I think, it is sometimes good to get rid of them in the actual project but keep them easily accessible. So an export feature might be helpful.
These were just ideas before breakfast, there are exactly 4 features that I would love Scrivener to have, but they will not be implemented the way I personally like (which is absolutely OK for me), all other features are not essential to me. I was just brainstorming. Basically Scrivener is developed for my needs. I live in Scrivener when I am not working outdoor.
All the best,
Maria
A couple of things that just pop into my head when thinking about the Applescript are flags about the state of certain things, such as whether or not the program is in full screen mode. Some things I was thinking of, such as whether certain windows or palettes were visible probably falls under the Standard window object.
Also access to any statistics which aren't easily available from querying the text objects, like those which depend on user preferences.
If I think of something else, I'll let you know.
Also access to any statistics which aren't easily available from querying the text objects, like those which depend on user preferences.
If I think of something else, I'll let you know.
-
jeremydouglassje
- Posts: 38
- Joined: Tue Jan 09, 2007 10:38 pm
I'd probably use Scrivener Applescript support to grab individual documents / resources out of scrivener and stick them in an archive (e.g. EagleFiler, Yojimbo/DevonThink, etc.) or move rss and bookmarked resources to or from web apps (e.g. WebNoteHappy, Pukka, NetNewsWire, Vienna etc.)
Example 1: Document database app support
I decide that something I've saved in my document database app (e.g. EagleFiler, Yojimbo etc.) would be handy in a Scrivener document, and I want to import it in a fine-grained way (mapping metadata). Or, conversely, I decide that something I collected in a Scrivener document is useful enough that I want to move it to my general archive.
So I might highlight a document (or documents?) in the Scrivener binder and run an Applescript to import copies into EagleFiler/Yojimbo. I'd want Scrivener dictionary entries for:
1. title
2. path (POSIX)
3. url (if any)
That should get me images, RTF documents, and weblocs/webarchives.
Bonus, I'd like the option to get:
4. abstract (-> description)
5. keywords (-> tags etc.)
6. datemodified, datecreated, status, label etc... any metadata, which I can then stuff in the script if I want at added to the target application.
Conversely, I highlight a document (or documents) in EagleFiler/Yojimbo and run a script to copy it into the Scrivener Research folder as a new entry (or new entries). I want to be able to write to a new object in the binder with Title, abstract, keywords, etc. For this, it might be nice to have an addressable "text" field so that I could directly assign what the new object would contain (most of these programs don't use a database made of RTF files, so passing a POSIX path isn't possible).
Example 2: Bookmarking
Exactly the same, except with apps like NetNewsWire, WebnoteHappy, or Pukka. You can't write entries to RSS readers, but you might be subscribed to feeds and want to quickly and completely copy selected entries into your Scrivener Research folder - again perhaps by passing a title, url, and optional abstract/keywords/date-information. With bookmark managers, you likewise might want to import into Scrivener - or you might decide you want to push selected Scrivener resources with URL information out to your bookmark archive or a del.icio.us feed - other than title, url, and abstract, I'd definitely want to recover keywords and write them to tags - so it would be important to get the keywords output either as an array or as a string that supported space-delimited or comma-delimited format (space-delimited is the more popular target, I believe).
Those are my thoughts - I hope they are helpful if you decide to go ahead with this. If those entries were available, I could probably write a batch of scripts connecting the apps mentioned. If highlighting multiple documents in the Scrivener Binder allowed me to loop on my export scripts, that would also be excellent.
Example 1: Document database app support
I decide that something I've saved in my document database app (e.g. EagleFiler, Yojimbo etc.) would be handy in a Scrivener document, and I want to import it in a fine-grained way (mapping metadata). Or, conversely, I decide that something I collected in a Scrivener document is useful enough that I want to move it to my general archive.
So I might highlight a document (or documents?) in the Scrivener binder and run an Applescript to import copies into EagleFiler/Yojimbo. I'd want Scrivener dictionary entries for:
1. title
2. path (POSIX)
3. url (if any)
That should get me images, RTF documents, and weblocs/webarchives.
Bonus, I'd like the option to get:
4. abstract (-> description)
5. keywords (-> tags etc.)
6. datemodified, datecreated, status, label etc... any metadata, which I can then stuff in the script if I want at added to the target application.
Conversely, I highlight a document (or documents) in EagleFiler/Yojimbo and run a script to copy it into the Scrivener Research folder as a new entry (or new entries). I want to be able to write to a new object in the binder with Title, abstract, keywords, etc. For this, it might be nice to have an addressable "text" field so that I could directly assign what the new object would contain (most of these programs don't use a database made of RTF files, so passing a POSIX path isn't possible).
Example 2: Bookmarking
Exactly the same, except with apps like NetNewsWire, WebnoteHappy, or Pukka. You can't write entries to RSS readers, but you might be subscribed to feeds and want to quickly and completely copy selected entries into your Scrivener Research folder - again perhaps by passing a title, url, and optional abstract/keywords/date-information. With bookmark managers, you likewise might want to import into Scrivener - or you might decide you want to push selected Scrivener resources with URL information out to your bookmark archive or a del.icio.us feed - other than title, url, and abstract, I'd definitely want to recover keywords and write them to tags - so it would be important to get the keywords output either as an array or as a string that supported space-delimited or comma-delimited format (space-delimited is the more popular target, I believe).
Those are my thoughts - I hope they are helpful if you decide to go ahead with this. If those entries were available, I could probably write a batch of scripts connecting the apps mentioned. If highlighting multiple documents in the Scrivener Binder allowed me to loop on my export scripts, that would also be excellent.
-
jeremydouglassje
- Posts: 38
- Joined: Tue Jan 09, 2007 10:38 pm
Regarding the above discussion of parsed binder imports: a number of interesting advanced effects could be pulled off with Binder manipulation routines, however my two-cents would be to first focus on entirely implementing access to individual entries and entry collections, and create a basic way of dumping a new entry into the Binder.
My thinking on this is that scriptable Binder manipulation is a big can of worms, and you can do most things without it - for example, if you wanted to parse a large import document by headers, you can write the pieces to the bottom of the binder in parse order and then let the user drag them wherever, all without any addressable Binder manipulation terms at all. Its only in importing *nested* outlines that you would need to support insertion points or outliner-like commands.
I'm not against rich addressable binder manipulation via applescript - I'd just suggest that you make that the Scrivener Applescript Dictionary 2.0 rather than 1.0 goal, and start by putting out the basics so people can test it for you with scripts.
My thinking on this is that scriptable Binder manipulation is a big can of worms, and you can do most things without it - for example, if you wanted to parse a large import document by headers, you can write the pieces to the bottom of the binder in parse order and then let the user drag them wherever, all without any addressable Binder manipulation terms at all. Its only in importing *nested* outlines that you would need to support insertion points or outliner-like commands.
I'm not against rich addressable binder manipulation via applescript - I'd just suggest that you make that the Scrivener Applescript Dictionary 2.0 rather than 1.0 goal, and start by putting out the basics so people can test it for you with scripts.
-
KB
- Site Admin
- Posts: 20716
- Joined: Tue Jun 13, 2006 11:23 pm
- Platform: Mac
- Location: Truro, Cornwall
- Contact:
Thanks - this is very helpful. Yes, for a start I definitely just want to go with the most useful basics. I don't want to open up a whole host of potential new problems just yet, and I don't want to dedicate too much development to this at this stage, either - I just want to add the basics that will enable some useful scripting for inter-app support. A lot of your suggestions make sense, Jeremy, and I will look into them. Amber - I am looking at OO Pro's AppleScript support and it is impressive, though obviously Scrivener won't be able to offer that sort of extensive support at this stage, as you note yourself.
Thanks!
Keith
Thanks!
Keith
-
Lord Lightning
- Posts: 652
- Joined: Fri Jun 23, 2006 4:58 am
- Location: Somewhere else!
I am a modern Major General and I made a little list;
convert - text to pdf
convert or format - to multimarkdown
convert - all caps
convert - lower case
convert - plain quotes
convert - smart quotes
image - duplicate
image - flip
image - rotate
delete - trash folder
move - to pre-trash folder
insert - current date and time
create - vertical split
create - horizontal split
speak - text
url - Scrivener forum
append - note
create - index
create - note from selection
import - image
import - Screenwriter script
import - Final Draft Pro script
import - Montage script
insert - date and time
Just idea starters.
convert - text to pdf
convert or format - to multimarkdown
convert - all caps
convert - lower case
convert - plain quotes
convert - smart quotes
image - duplicate
image - flip
image - rotate
delete - trash folder
move - to pre-trash folder
insert - current date and time
create - vertical split
create - horizontal split
speak - text
url - Scrivener forum
append - note
create - index
create - note from selection
import - image
import - Screenwriter script
import - Final Draft Pro script
import - Montage script
insert - date and time
Just idea starters.
Lord Lightning
I'm a writer. I create worlds!
When I make a declarative statement it applies to ME. Not to everyone.
I'm a writer. I create worlds!
When I make a declarative statement it applies to ME. Not to everyone.
Importing of Mail.
• Scrivener – Nisus – Bookends – Devonthink – Lightroom
• MacMini 2018 / MacBook Pro 2014 (10.14.6) – iPhone 7 (12.4)
I went there and came back / It was nothing special / The river at high tide / The mountain veiled by misty rain
• MacMini 2018 / MacBook Pro 2014 (10.14.6) – iPhone 7 (12.4)
I went there and came back / It was nothing special / The river at high tide / The mountain veiled by misty rain