分类 Apple系列 下的文章

我去年有简单聊过为什么从网易云音乐切换到苹果音乐,并且跟各位简单分享了我的使用思路。但随着资料库内容逐渐复杂,我的思路进行了一些调整。今天就简单的跟你分享一下。

首先,随着版本的更新, 新的苹果音乐已经单独提供我喜爱的音乐播放列表了。因此之前通过智能播放列表实现的喜爱歌单就不再需要了,删除即可。

其次,由于现在有使用古典乐app,而古典乐与音乐的资料库是同步的,所以在古典乐中加入到资料库的作品同样可以在苹果音乐的资料库中看到并收听。但当我在驾驶途中想从资料库随机播放音乐时,古典乐混入其中就有一丝不和谐的感觉。因此增加一个智能播放列表,将所有不想在驾驶途中收听的音乐排除掉的一个大合集歌单。

在电脑端的苹果音乐中新建智能播放列表,条件如下:

  • 类型不包含classical与类型不包含spoken word:这两个条件相结合排除掉了所有的古典乐文件,同时spoken word条件可另外将所有专辑中的讲话片段进行了筛选——目前我发现的仅仅在维也纳新春音乐会专辑中有发现,可能有些现场版专辑也会呈现吧
  • 时长大于1分钟:这个条件将一些音乐片段进行过滤。以我的资料库来看,只有TV放送版专辑涉及此情况。
  • 注释不包含剔除:这是一个十分灵活的条件,可以将所有游离在前三个筛选条件以外的,自己不想在驾驶途中收听的音乐剔除。比如前述的TV放送版专辑中,存在两个正片BGM音轨。这两个音轨超过了1分钟时长但个人感觉不太适合在驾驶途中收听,因此便可以通过这个条件进行剔除。

那么如何将最后的这个条件实际应用起来呢?

在电脑版苹果音乐中,在资料库内找到需要剔除的音乐,右键——显示简介,弹出的窗口最下面有注释一行,在后面填入“剔除”两字,按下好完成编辑即可。

听起来是一个挺蠢的方法吧?但这只是给你分享一下我自己构造这个歌单的思路。通过类型及时长将大多数不希望出现在这个歌单的曲目筛掉,零星的没有共性的音频再通过注释进行补齐,真正实现起来要比手工整理大合集歌单简单、快速的多,可以试试。

最后,通过播放列表文件夹将播放列表进行归类。比如我这里增加了两个文件夹:每年都在听什么与年度精选。其中,每年都在听什么存储了我的按年整理的播放列表——注意啊,按年整理的播放列表也是智能播放列表,我不需要手工将新加入资料库的音乐添加进去,它会自动同步资料库的变更。而年度精选则保存了苹果音乐每年自动生成的音乐回忆。这样一来有两个优势,一来可以通过分类快速找到相应的播放列表进行播放。另一个更大的优势是可以将这些播放列表的音乐直接合并播放。举个例子:我这里有两年的音乐回忆,如果我不放在文件夹中,那么我每次只能在某一个音乐回忆列表中进行播放。想将两个列表合并播放的话,我只能在开始播放某一个列表之后,长按另一个选择最后播放将其加入到队列之中。而放入文件夹,显而易见的,在两个列表的界面便出现播放按钮了。

那么现在我的苹果音乐是一个什么使用效果呢?对于一般的流行乐,我遇到喜欢的歌曲之后只需选择添加到资料库,按年整理的智能播放列表与驾驶使用的智能播放列表会实时进行更新。对于我特别喜欢的乡村音乐,因为我为这种曲风单独建立了播放列表,而这个就像我之前提到的,音轨的分类不统一,只能使用普通的播放列表。那么对于这种涉及到手工编辑播放列表的场景,我只需增加音乐到这个播放列表,苹果音乐的设置项会将这个音乐添加到资料库,然后又回到了前面的智能播放列表筛选环节。如此,更新的自动化、一键式歌单整理就调整完成了。

还是那句话,以上只是给各位提供一个苹果音乐的使用思路,各位可以根据自己的实际使用场景对智能播放列表的条件进行调整,打造属于自己的一键式智能音乐播放器。

1月14号,我在苹果音乐的古典乐模块发现了古典乐应用即将上架国区苹果商店,便立刻进行了预订,并在23日半夜时候第一时间进行了安装。经过这段时间的使用,我感觉相比于流媒体音乐软件,说它是古典乐百科更为合适。

先来简单看看古典乐应用与音乐应用的差别。

打开古典乐,第一眼便可以发现古典乐应用没有广播这种按喜好推荐功能。

在资料库页面,古典乐的分类筛选是不可编辑的,分类方法同音乐也有着较为明显的差别。且古典乐的资料库没有最近添加列表,如果需要查找,必须点击到某一种分类方式当中来查看。

正在播放页面,古典乐的所有文本展示部分都进行了多行化处理,且左下角的歌词按钮被详细信息按钮所取代,可以通过这个功能查看正在播放曲目的元数据。

待播清单功能,古典乐不提供乱序及无限播放,仅可以针对当前播放列表进行循环顺序播放。

对已经添加到资料库的曲目,古典乐不提供下载。

现在切换到浏览页面,可以发现两者有着天壤之别。

音乐通过各种分类及标题向用户推送各种在线音频,而古典乐直接通过三种维度提供分类参考,用户需要通过选择来进入到固定的浏览页。在这个页面中,可以查看所选类型的基本概述,以及涉及到该分类的专辑、作品、作曲家等,进而限定到具体的作品中进行播放。

到了现在就听界面,乍一看两者呈现的方法类似,但细看便可发现,古典乐的现在就听没有自动建议板块,所有内容均为专辑或人工筛选组合的播放列表。

搜索也有很大不同。古典乐毕竟只有古典乐一个主题,所以没有类别浏览的需要,取而代之的是进行关键词推荐。

所有的变化,都使得古典乐应用很难做到苹果音乐一样的漫无目的的使用体验,而是更着重于有目的的查找并播放。而这可能来源于古典乐同流行音乐的“代沟”。这里先来简单了解一下古典音乐的一些小知识。

众所周知,古典音乐来回来去就那些。因此古典乐同流行音乐的最主要区别便是它被“数据库化”了。这个数据库包含了几个主要维度。

  • 体裁:这部作品都需要哪些乐器参与其中。
  • 体裁中编号:同一体裁作品的排序编号。
  • 调性:作品所使用的音阶。
  • 作品编号:此作品所属作曲家的排序编号。
  • 标题:作曲家自拟或后人所起的俗名。
  • 乐章编号:人为在一部作品中按照某种标准进行分段后的排序编号。
  • 乐章速度:呃……好像这个没啥能解释的,就是指演奏快慢。

下面看一个例子:Piano Sonata No. 14 in C-Sharp Minor, Op. 27 No. 2 "Moonlight": I. Adagio sostenuto

  • 体裁:Piano Sonata,钢琴奏鸣曲
  • 体裁中编号:第14
  • 调性:升C小调
  • 作品编号:27号中的第2首
  • 标题:月光
  • 乐章编号:1
  • 速度:Adagio,柔板

这,便是童年阴影——名侦探柯南《月光奏鸣曲杀人事件》所引用的古典乐学名。

通过这个例子便可以看出,古典乐的命名方式是制式的,相对流行音乐来说更死板,但与此同时,检索会更加方便。就以《月光》为例,即使不使用标题检索,我们也可以简单的通过作曲家+作品编号来快速确定作品——贝多芬 Op 27.

这种检索能力,在古典乐app中被明显加强。相对于苹果音乐的平铺检索结果,古典乐会根据所检索的作品给出一个集合页面,你可以在这里看到关于这部作品的介绍、包含此作品的专辑以及此作品的热门录音。

但是我们也可以发现,单单靠搜索作品查找到的范围还是有些太广了,如果想进行一些筛选的话就还需要增加一些关键词,比如演奏者的名称。这里增加一个皇家爱乐管弦乐队。

现在,通过古典乐应用我们就定位到所有由皇家爱乐演奏的月光奏鸣曲录音了。而通过同样的关键词在音乐应用中检索,我们会发现它查找了所有演奏者为皇家爱乐的曲目,而忽略了月光这个作品名的限定条件。这也是我认为苹果古典乐相对于苹果音乐最关键的区别所在。

那接下来,简单来谈谈为什么我认为古典乐不太能被看作是流媒体音乐播放器。广义来说这其实没什么问题,但当前的音乐软件,最简洁的也得像苹果音乐那样,至少包括一些根据用户喜好进行诸如随机推荐之类的,可以被用户习惯所训练的个性化功能。而反观古典乐,将本就不多的苹果音乐的这些功能进一步删减。连现在就听中的内容也是按照专辑,或者人工编辑的播放列表进行整体推荐,直观上看不到用户训练的效果反馈。

这可能又涉及到古典乐同流行音乐在音频文件分割上面的差异了。拿这个专辑来看:

此专辑包含3部作品,但除了第二部为单一乐章以外,另外两部全部由多乐章组合而成,而从存储的角度上面来看,每一个乐章对应着一个音频文件。因此如果只挑选某一个音频文件播放,那么大概率只能听到一段没头没尾的音乐。而这种存储方式可能也是古典乐应用没有算法推荐、没有随机播放功能的原因之一。

在预订页面,官方对这款应用的描述是这样的:在聆听音乐的过程中,《Apple Music古典乐》还会呈现专业介绍,带你了解古典名家名作,通过艺人分享,让你近距离接触喜爱的音乐家,丰富你的古典音乐知识。确实,古典乐应用从界面到操作都专门为古典乐特殊的结构进行了优化。而为人物、乐器所设计的头像,现在就听中的“音乐家亲选曲目单”模块,以及为每一个人物、每一种乐器、每一部作品所编写的生动介绍,都让古典乐应用更像一个古典乐版本的维基百科,而非苹果音乐的“同质化应用”。

目前,苹果音乐古典乐已填补了东亚地区的空缺,在此区域内订阅苹果音乐个人版以上的用户可以直接下载体验。

视频点此

如果你使用iOS系统的话,应该会注意到快捷指令app中“我的快捷指令”与“自动化”两个标签。今天,简单来介绍一下我认为比较新颖的使用思路。

首先来说如何使用快捷指令呢?在快捷指令界面下,一个标签就是一个快捷指令执行的功能,使用的时候直接点击对应的标签即可。

或者在可以直接在桌面增加快捷指令的小部件,点击运行;又或者可以直接将快捷指令发送到桌面图标(只需要在快捷指令app中,点击需要发送到桌面的快捷指令模块右上角的三个点,再点击右上角设置—添加到主屏幕,设置好图标和名称之后确认添加即可。

对于快捷指令的自动化界面也很容易理解。就是在特定的条件下自动去触发某一系列操作。

仔细查看一下两个界面可以添加的动作就会发现,快捷指令模块和自动化模块可以添加的动作几乎是一样的,那么为什么会出现这两个界面呢?

我个人认为,之所以把自动化放在了快捷指令的后面,是因为我们可以把快捷指令界面的每一个按键理解为一个函数,自动化可以去引用这些函数。

你可能不是很能理解为什么要通过引用来实现本可以在自动化中直接编写出来的操作,这里我直接举一个例子,也许就能体会到引用的优势了。

就像前面截图,我有一个更换表盘的快捷指令。这个快捷指令中只有一个动作:将Apple Watch表盘调整为团结之光。那么在自动化中,我设定了每天晚上八点半和打开工作专注模式的时候,将表盘设置到团结之光。诚然,我可以直接起两个自动化,每个自动化里边都直接使用更换Apple Watch表盘的功能来实现这个操作,但这里我选择了在两个自动化中调用更换表盘的快捷指令来实现。因为如果出现了新表盘,我想在这两个节点更换到新表盘时,我可以通过修改快捷指令里边的表盘来直接调整两个自动化所做的动作,而不再需要前往每个自动化分别设定了。

通过快捷指令来实现一个“函数”,在多个自动化中直接调用,来简化之后维护的复杂性,这也许就是为什么快捷指令与自动化放在同一个软件中,自动化还排在快捷指令后面的原因之一吧。

视频点此

一个很简单的想法,源于我的KDE桌面——要知道,我的KDE桌面壁纸设置的就是每日一图,bing来源。

思路也很简单。现如今iOS系统已经预置了一个十分方便但异常强大的组件:快捷指令,而根据KDE可以使用bing每日一图来推断,便可知道bing的图片接口是开放的。所以前提条件都准备好了,就直接来编写快捷指令吧。

打开快捷指令,新建。

首先就是要获取bing当天推荐的图片。而获取的方法自然是通过Bing提供的API获取。

API地址如下:https://cn.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1

快捷指令中已经提供了从API获取js结果的功能,直接搜索添加获取URL内容,其中获取来源填入上面的API地址即可。

从这个网址获取到的结果是一个json字符。在快捷指令中,可以很方便的将json串转换为词典并从词典中提取指定键对应的值。而这也是作为互联网上面API使用最多的数据传输方法。上述Bing的API得到的json保存有很多信息。而我们只需要其中的图片路径即可。假定上述获取到的json命名为Bing,那么它有关图片地址的键就在Bing.images.url。而这个路径并不是完整的,它没有保存这个图片对应的通用的网址前缀。而这个前缀就是Bing的网址https://www.bing.com/

在了解了上述规律之后,就可以继续完成这个快捷指令了。我们现在只是拿到了最初始的json字符串,接下来就是要解析并获取真正的图片了。而这些功能快捷指令都有着对应的功能。

增加一个功能获取词典值,来源位置会自动加入前一步骤得到的结果(URL的内容),也就是刚刚通过API获取的json。而为了之后简化路径,可以在这里先进行一次筛选,使之后的选择可以以Bing.images中进行。

点击URL的内容,弹出的小窗口中,类型(第二行蓝字位置)选择词典

下方获取键对应的值输入images,完成。这样变把此处的来源变成Bing.images里的内容了。

这个功能的后方,输入网址对应的键名url,获取的是

设置完成后这个功能整体表现出来的是这样的:

得到了URL,现在就可以补全URL来获取图片了。但是要注意,这里还是通过网址来获取的,所以使用的功能仍然是获取URL内容,而路径要输入完成的,补全的路径。因此需要在默认填入的词典值前面加上通用前缀https://www.bing.com/。整体看起来是这样的

最后,把获取到的墙纸设置为得到的图片即可。添加一个操作,名为设定墙纸,根据自己的需要,选择设置锁定界面还是主界面,而来源里边默认加入的URL的内容要注意,因为获取到的是图片,所以需要把类型设置为图像。如图。

同时,展开这个功能折叠的内容,关闭显示预览(否则执行后会进入到设定壁纸的预览界面,手工确定才能完成,就不符合原始的需要了。

视频点此

苹果家族的软件以封闭闻名,但macOS是一个例外——毕竟历史原因使得它除了图形界面以外都有规律可循。所以当使用Linux的思维去理解macOS的时候,就发现了一些到目前为止都没见过有谁提到过的有趣的细节。

我曾经在以前的内容中说过神奇的快捷方式——软链接。当时我就说过这玩意儿在Windows下用处不多,但Linux和macOS下用途很广。那时候我说这句话其实还是有些心虚的,因为我只用过Linux,对macOS的情况不是很了解,仅仅是为Linux和macOS的内核相似才得出的那个结论。但现在不一样了,我真正使用过macOS了,所以对于这个结论,我只能说:macOS同样很频繁的在使用软链接,可能比Linux更甚。

因为它为每个程序都软连接出来了一整套用户根目录,形成了一种沙盒机制。

我们可以简单领略一下:在home文件夹,打开资源库——你可能过需要按下cmd+shift+.来显示这个文件夹,或通过显示设置使它取消隐藏属性。

打开资源库,你会看到一个名字为Containers的文件夹。顾名思义,这里是用户程序的容器集合。打开它,你便能看到很多熟悉的面孔。

如果你有兴趣的话可以把每个文件夹都打开看看。这里我就直接跟你说结论吧:这里边一个文件夹就是macOS为一个程序准备的一个沙盒——或者说,一套用户home。为什么这么说呢?我们随意打开一个你就会看到。

是不是很熟悉?是的,这里边的文件夹结构与home是一模一样的,只不过这里多了Library、SystemData和tmp。

但是还是有些许不同的地方。注意到有几个文件夹左下角的小箭头了吗?错了,它不是普通的快捷方式,而是软链接。我们通过终端来看一下它们连接到的具体位置。

没有错,这些软连接都指向了我们的home。具体来解释一下:桌面、下载、视频、音乐、图片四个文件夹是与用户目录同步的,而文档、库、系统数据、临时文件每个程序都是单独占有的。这就使得在程序看来,自己是这个系统上唯一的程序,还可以在这个系统里边随意玩耍;而在macOS系统看来,每个程序就算玩出天来,也没能逃脱分配给它的这个乌托邦中。莫名的让我想到了缸中之脑理论…

那么如此设计的优势在哪儿呢?就我个人的感受,相对于另外两种系统来说,如此存储使得每个程序都有着相对隔离的系统环境,最大程度的避免依赖问题——任何系统都需要依赖,不只是Linux;而且所有文件都建立在了一个统一的位置,当卸载软件时直接删除这个文件夹便清理掉了由这个软件带来的所有文件——当然,音视频文档会保留,因为是软链接到了用户目录下。而与之相对的,就用户或者系统的视角来看,想去到一个程序的目录下路径就会变得异常复杂,以至于如果不耐下心来找的话会很难找到。

不过,既然找到了,就可以进行一些骚操作了。比如说微信电脑端、QQ电脑端的无限期云端同步功能。